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ABSTRACT 


To  achieve  integration  of  the  Naval  Meteorology  and  Oeeanography  (METOC) 
eommunity  into  the  developing  FORCEnet  environment,  transformational  innovations 
must  be  researehed  and  implemented.  Agent  based  software  is  an  example  of  teehnology 
that  ean  be  employed  in  this  way  by  ehanging  the  method  by  whieh  METOC  data  is 
distributed  to  end-users.  This  thesis  doeuments  the  ereation  and  implementation  of  a 
software  agent  that  uses  Internet  eonneetions  to  retrieve  numerieal  model  data,  loads  this 
output  into  array  data  eontainers,  and  then  makes  it  available  to  the  end-user  in  a 
maehine -readable  foreeast  objeet  format.  The  impaet  of  the  importation  of  this  foreeast 
objeet  into  warfare  eommander  eommand-and-eontrol  software  is  then  assessed  using  the 
eommereially  available  SEAWAY  logisties  tool.  This  assessment  highlights  the 
importanee  of  defining  the  METOC  funetional  requirements  for  the  emerging  FORCEnet 
environment,  so  that  proper  interfaees  to  exehange  data  freely,  and  visually  depiet  it,  are 
ineorporated  during  next  generation  software  development.  Using  these  types  of  agents  to 
automate  the  generation  and  delivery  of  weather  parameters  eould  also  allow  the 
importation  of  data  into  previously  insular  software,  provide  reaeh-baek  support  to  the 
warfighter,  and  be  a  means  of  redueing  manpower  and  budgetary  requirements  during 
this  time  of  fiseal  eonstraint. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Within  the  context  of  our  advancing  information  age,  modem  warfare 
commanders  must  manage  and  interpret  data  effectively  or  they  may  become 
overwhelmed  by  it.  In  many  cases  a  warfare  planner  will  have  an  overwhelming 
abundance  of  data  available  concerning  his  target.  As  a  result,  it  becomes  the  task  of  his 
staff,  or  supporting  commands,  to  sift  through  the  available  data,  produce  meaningful 
information,  and  “bubble  to  the  surface”  the  vital  10%  of  that  information  that  the 
commander  must  be  aware  of  in  order  to  make  able  decisions  concerning  the  tactical 
employment  of  assets.  In  his  class  on  Autonomous  Agents  at  the  Naval  Postgraduate 
School,  Prof.  John  Hiles  referred  to  this  as  an  attention  focus  system.  This  view  of  an 
attention  focus  system  that  feeds  information  to  a  warfare  planner  can  be  extended  to 
include  meteorological  data  as  well.  Within  this  discipline,  huge  stores  of  database 
numeric  model  output  are  already  available  and  better  means  of  automating  the 
interpretation  of  these  is  required. 

In  addition  to  receiving  focused,  relevant  information,  warfare  commanders  must 
be  given  that  information  in  the  format  that  is  most  applicable  to  them.  In  some  cases 
this  may  be  in  the  form  of  verbal  briefings  from  an  attached  Meteorology  and 
Oceanography  (METOC)  Officer  as  the  operational  and  meteorological  picture  develops. 
In  many  other  cases  this  may  mean  providing  utility  so  that  commanders  can  display 
environmental  conditions  and  their  impact  upon  assets  within  the  same  software  they 
utilize  for  planning.  Ultimately  how  that  information  is  provided  should  depend  only  on 
the  preferences  of  the  customer,  not  on  the  limitations  of  our  system  of  dissemination. 
Indeed,  as  the  sciences  that  define  how  we  handle,  process,  and  pass  information  continue 
to  advance  at  an  astounding  rate,  commanders  should  have  access  to  whatever 
information  they  need  in  whatever  manner  they  desire. 

As  stated  above,  then,  there  are  two  central  issues  to  be  examined  when 
considering  how  best  to  deal  with  meteorological  data.  The  first  is  how  that  data  is 
processed  and  focused  into  relevant  information.  The  second  is  how  to  pass  that 
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information  on  to  warfare  commanders  that  makes  use  of  a  flexible  architecture  that  takes 
advantage  of  our  progressing  information  age. 

B,  PROCESSING  DATA  AND  PASSING  INFORMATION  -  THE  WAY  IT  IS 

In  order  to  develop  and  validate  new  ways  of  processing  and  passing 
meteorological  information,  we  must  at  least  briefly  examine  the  manner  in  which  we 
currently  perform  these  tasks.  In  the  U.S.  Navy,  meteorology  professionals  currently 
receive  numeric  model  output,  review  it,  and  then  provide  their  customers  with  forecast 
information  in  one  of  several  ways.  The  most  basic  example  of  a  meteorology  product  is 
a  forecast  of  environmental  conditions  for  a  given  location  and  time.  This  is  a  forecast 
that  may  be  for  a  specific  point  or  may  cover  a  larger  region,  but  in  either  case  consists  of 
a  simple  listing  of  parameters  such  as  temperature,  wind  speed,  etc.  A  more  evolved  type 
of  operational  forecast  is  one  that  considers  the  impact  of  meteorological  conditions  on  a 
specific  type  of  asset  or  platform  that  is  designed  for  use  in  a  certain  manner  during  a 
planned  operation.  This  may  take  the  form  of  a  “stoplight”  type  graphic,  which  we  will 
discuss  further  shortly,  or  be  represented  as  a  tactical  decision  aid  (TDA)  of  some  type.  A 
third  method  of  providing  forecast  information,  and  the  one  most  often  preferred  by 
customers,  is  to  have  a  forecaster  on-scene  working  directly  with  the  operators  during  the 
development  and  execution  of  a  military  exercise  or  mission.  Each  of  these  methods  has 
advantages  and  disadvantages,  which  will  be  examined  individually  before  an  alternate 
means  of  producing  and  disseminating  meteorological  forecasts  is  proposed. 

It  is  important  to  first  consider  how  meteorological  data  is  currently  processed 
within  the  Navy  METOC  community.  Today,  the  officer  and  enlisted  personnel  that 
comprise  the  METOC  community  wear  many  hats.  Along  with  a  very  wide  range  of 
tasking,  however,  their  main  duty  has  always  been  to  produce  forecasts  of  environmental 
conditions  and  often  to  also  evaluate  how  these  factors  will  impact  a  mission.  In  a  sense, 
they  take  the  raw  numeric  model  output,  apply  to  this  data  a  nuanced  understanding  of 
both  local  effects  and  model  tendencies,  and  then  produce  usable  information  in  terms  of 
an  environmental  forecast  or  impact  assessment.  The  important  point  to  emphasize  here 
is  that  the  data  is  essentially  processed,  given  context,  and  evaluated  within  that  human 
forecaster’s  mind. 
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As  we  examine  the  forms  in  which  forecasts  are  sent  to  customers  within  the 
Navy  it  is  logical  to  begin  with  one  of  the  most  widely  used  and  traditional  methods.  This 
means  of  forecasting  is  to  send  information  to  receiving  units  as  a  simple  list  of 
environmental  parameters  of  interest  during  a  specific  period  of  time.  This  sort  of  support 
can  take  many  forms,  it  can  be  sent  via  naval  message  traffic,  IRC  chat,  or  even  classified 
or  unclassified  e-mail,  and  is  usually  re-issued  on  a  regular  hourly  interval  as  per  the 
request  of  the  customer.  It  is  not  so  much  the  form  or  regularity  of  this  type  of  forecast 
that  is  of  particular  interest.  It  is,  instead,  the  assertion  that  these  forecasts  include  no 
interpretation  of  the  environment,  but  rather  a  detailed  description  of  it.  This  requires  the 
forecaster,  who  is  often  well  outside  of  the  operating  area,  to  generate  a  product  based  on 
a  point  latitude/longitude  position  and  time  period.  The  recipient  then  has  to  read  the 
message  and  put  it  into  context  by  considering  the  impact  of  the  forecasted  conditions 
upon  the  type  of  operation  planned  for  execution.  This  format  allows  the  Navy  to 
consolidate  its  forecasting  assets  into  the  geographic  METOC  Centers  that  are  in 
existence  today.  Such  efforts  can  reduce  the  manpower  required  to  support  units  spread 
over  a  large  region  and,  by  extension,  also  reduce  the  budget  and  logistic  footprint 
necessary  to  do  so. 

The  drawbacks  to  sending  forecast  information  as  a  list  of  parameters  from  a 
remote  location,  however,  are  copious.  First,  individuals  who  may  be  hundreds,  or  even 
thousands,  of  miles  away,  are  producing  these  forecasts.  This  may  result  an  unclear 
understanding  of  locally  produced,  microscale  phenomenon.  This  distance  from  the 
customer  can  also  make  relaying  information  or  updating  the  operational  picture 
extremely  difficult.  As  an  example,  if  a  customer  needs  to  change  the  type  of  operation 
they  will  be  conducting  on  short  notice,  there  may  not  be  enough  time  to  relay  this 
information  to  the  nearest  METOC  Center.  As  a  result,  the  operators  are  left  with  a 
forecast  that  is  of  either  little  or  no  use  to  them  because  they  have  changed  location, 
timeframe,  or  asset  employment.  In  this  type  of  situation,  the  meteorology  professional 
may  also  not  be  aware  of  when  they  should  amend  their  forecast  due  to  quickly  changing 
conditions.  This  could  result  in  a  loss  of  their  credibility  from  the  viewpoint  of  the 
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customer.  The  onus  for  determining  the  impact  of  environmental  parameters  is  plaeed 
entirely  on  the  receiving  unit,  while  the  forecaster  is  relieved  of  the  responsibility  of 
making  such  assessments. 

Another  manner  in  whieh  foreeast  information  is  provided  to  customers  is  as 
“impact-eentrie”  information.  In  this  approach,  the  METOC  community  member  is  made 
aware  of  what  type  of  assets  or  platforms  will  be  used  during  an  operation.  Then  a 
foreeast  is  produeed  in  a  similar  manner  as  before,  but  an  additional  layer  of  context  is 
applied  to  the  problem  by  the  foreeaster  as  they  consider  how  these  conditions  will 
impact  the  equipment  that  will  be  used.  An  example  of  this  type  of  produet  is  a 
“stoplight”  graphic.  These  use  a  red,  yellow,  or  green  eolor  code  to  represent  the  severity 
of  degradation  an  asset  will  experience  as  a  result  of  environmental  conditions.  The  color 
code  is  assigned  by  the  meteorology  professional  based  on  the  type  of  platforms  planned 
for  use,  their  safe  operating  thresholds,  and  the  foreeasted  eonditions.  It  should  be  noted 
that  this  type  of  assessment  ean  also  be  produced  from  a  regional  METOC  Center,  and 
therefore  ineorporates  the  benefits  and  deficieneies  previously  mentioned.  In  addition,  the 
forecaster  must  now  have  an  aceurate  understanding  of  exactly  which  types  of  equipment 
will  be  used.  If  another  type  of  asset  is  substituted,  an  assessment  may  not  be 
immediately  available. 

Another  example  of  a  kind  of  “impaet-eentrie”  assessment  is  the  TDA.  These  are 
software  units  that  have  been  designed  to  speeifically  evaluate  the  impaet  of 
environmental  eonditions  on  a  partieular  kind  of  operation  employing  distinet  assets. 
Generally  these  lack  flexibility  since,  by  definition,  they  are  geared  to  solve  only  one  type 
of  specialized  problem.  Sinee  these  modules  are  generally  smaller,  however,  they  are 
usually  more  transportable  and  a  non-METOC  individual  can  be  trained  to  use  them  if 
neeessary. 

A  third  method  of  providing  foreeast  information  in  support  of  an  operation  is 
through  the  assignment  of  an  attached  METOC  foreeaster.  In  this  situation  there  is  either 
an  officer  or  enlisted  service  member  that  is  traveling  with  the  eommander  and  is  on¬ 
scene  to  provide  immediate  updates  to  the  environmental  picture.  The  foreeast  is  still 
produeed  using  numeric  model  output  as  before,  but  now  an  individual  is  present  with  the 
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customer  to  incorporate  any  type  of  context  they  may  desire  and  evaluate  the  information 
in  that  manner.  Customer  response  to  this  kind  of  response  is  usually  overwhelmingly 
positive,  sinee  it  is  an  augmentation  of  their  manpower  and  they  can  work  closely  with 
that  assigned  individual  to  tailor  the  support  in  whatever  way  they  desire.  Praetieally, 
however,  this  means  of  providing  environmental  services  is  manpower  intensive, 
logistically  intrieate,  and  a  strain  on  monetary  resourees,  whieh  makes  it  undesirable 
exeept  in  isolated  cases. 

C.  PROCESSING  DATA  AND  PASSING  INFORMATION  -  THE  WAY  OF 

THE  FUTURE 

In  an  artiele  he  wrote  as  the  Director  for  the  Office  of  Foree  Transformation,  Vice 
Admiral  (ret.)  Cebrowski  defined  transformation  as  “a  eontinuing  proeess...  [that]  is 
meant  to  deal  with  the  eo-evolution  of  eoneepts,  processes,  organizations  and  teehnology. 
Transformation  is  meant  to  identify  and  leverage  new  sourees  of  power.”  (Cebrowski, 
OFT).  In  a  presentation  he  gave  on  24  February  2004,  CAPT  Chris  Gunderson  expanded 
upon  this  statement  by  saying  that  transformation  was  the  utilization  of  teehnologieal 
advanees  within  our  current  “information  age”  eombined  with  increasing  efforts  to 
expand  globalization  (Gunderson,  2004).  These  principles  are  uniquely  suited  for 
immediate  application  within  the  METOC  community  in  terms  of  how  we  process 
meteorological  data  and  exchange  that  information  with  our  eustomers. 

Figure  1  illustrates  how  transformation  ean  develop  by  combining  technological 
advancements  with  inereasing  interoperability.  This  diagram  depicts  advances  along  the 
globalization  axis  increasing  from  left  to  right,  and  advances  in  information  age 
teehnologies  increasing  from  bottom  to  top.  The  examples  of  globalization  range  from 
eombining  inter-serviee  meteorological  numeric  models  to  the  utilization  of  coalition 
forces.  Advances  along  the  information  age  axis  inerease  from  the  use  of  software  agents 
to  the  employment  of  wireless  networks  and  advaneed  mieroseale  modeling.  The 
advanees  along  eaeh  individual  axis  meet  along  the  dashed  line,  whieh  represents 
progress  towards  transformation,  whieh  in  this  ease  is  applied  to  the  field  of  Navy 
meteorology.  These  are  examples  of  teehnologies  that  are  either  available  now  or  in 
development,  and  would  only  require  an  open,  innovative  mindset  and  effective 
leveraging  in  order  to  make  them  a  reality. 
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The  handling  of  data  has  long  since  moved  from  the  realm  of  simple  storage 
medium  into  a  more  advanced  representation  of  how  that  data  may  interrelate  and  come 
to  represent  information.  An  example  of  this  would  be  the  development  of  relational 
databases,  which  sought  to  do  more  than  simply  store  the  data  they  contained.  In  a  similar 
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Figure  1.  Working  Towards  Transformation. 


way,  other  advances  in  how  data  is  represented  and  processed  have  become  more  focused 
on  the  context  of  data  and  automating  interpretation.  One  such  advancement  has  been  the 
development  of  software  agents.  Though  they  will  be  examined  in  much  greater  detail  in 
the  next  chapter,  software  agents  are  essentially  autonomous  modules  that  can  be 
programmed  to  perform  various  tasks  that  could  include  data  manipulation  and 
interpretation.  This  type  of  automation  could  potentially  streamline  the  process  for 
producing  a  forecast,  depending  on  the  format  of  the  final  product  and  the  levels  of 
context  that  must  be  applied  to  generate  it. 

Advances  in  how  information  is  passed  that  are  independent  of  hierarchical 
stovepipes  are  an  example  of  increasing  globalization.  There  can  be  no  doubt  that  as 
information  continues  to  travel  around  the  Earth  at  an  increasing  rate,  globalization  is 
happening.  Large  quantities  of  data  or  information  can  now  travel  from  one  point  to 
another  almost  instantaneously  at  the  touch  of  a  virtual  button.  If  there  is  any  problem 
with  receiving  and  using  that  information  it  is  usually  because  of  formatting,  which  may 


6 


be  dependant  on  a  particular  piece  of  software  or  interface.  This  highlights  the 
importance  of  creating  a  common  architecture  for  passing  information  that  will  also  serve 
to  enhance  its  usability  wherever  it  is  accessed. 

D,  THESIS  APPROACH  AND  GOALS 

This  thesis  describes  solutions  for  the  METOC  community  that  address  the  two 
means  of  advancement  proposed  above.  The  first  portion  of  this  thesis  will  consist  of 
coding  a  software  agent  in  the  programming  language  Java.  This  will  serve  as  a  fresh 
look  at  how  meteorology  data  is  processed  within  the  Navy,  and  evaluate  whether  or  not 
automation  in  this  area  is  something  that  would  be  possible  or  desirable.  The  second 
portion  of  this  thesis  will  encompass  the  passing  of  data  or  information  that  has  been 
output  by  the  developed  agent.  This  will  essentially  be  the  examination  of  a  new 
approach  as  to  how  to  standardize  the  means  by  which  exchanges  take  place.  Ideally,  this 
new  architecture  will  be  a  means  by  which  organizational  stovepipes  can  be  either 
bridged  or  eliminated.  For  research  purposes,  this  thesis  will  examine  how  the  developed 
agent  passes  information  to,  and  receives  information  from,  a  piece  of  decision  aid 
software.  Specifically,  this  software  will  be  the  SEAWAY  program  developed  by  CDM 
Technologies,  Inc  of  San  Euis  Obispo.  The  SEAWAY  program  will  be  detailed  for  the 
reader  in  a  later  chapter. 

The  expected  results  for  this  thesis  are  twofold.  The  first  anticipated  result  is  that 
the  creation  of  this  agent  will  enable  the  design  of  a  new  architecture  for  passing 
information  within  the  METOC  realm.  This  innovative  architecture  will  be  proposed  and 
then  evaluated  for  viability.  The  second  is  that  the  successful  example  of  a  software  agent 
that  is  specialized  for  use  within  the  METOC  community  will  allow  for  a  detailed 
examination  of  the  feasibility  of  this  type  of  programming,  as  well  as  a  critique  of  its 
potential  impact.  This  resulting  impact  assessment  will  also  highlight  the  need  for  the 
METOC  community  to  effectively  document  and  define  its  functional  requirements  for 
the  emerging  FORCEnet  environment. 
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II.  AGENTS 


A.  WHAT  IS  AN  AGENT? 

Interestingly  enough,  the  properties  that  exaetly  define  an  agent  are  a  point  of 
disagreement  among  eomputer  seientists  and  artificial  intelligence  researchers.  There  are 
as  many  different  listings  of  the  components  of  this  type  of  software  entity  as  there  are 
researchers  in  the  field.  So,  in  order  to  begin  a  discussion  on  this  topic  and  apply  it  to  the 
research  discussed  here,  a  general  definition  must  be  presented  and  agreed  upon.  In  his 
book  on  multiagent  systems,  Gerhard  Weiss  (Weiss,  1999)  defines  an  agent  as 
“autonomous,  computational  entities  that  can  be  viewed  as  perceiving  their  environment 
through  sensors  and  acting  upon  their  environment  through  effectors”.  He  also  stresses 
that,  “there  is  a  general  consensus  that  autonomy  is  central  to  the  notion  of  agency”. 
These  two  basic  definitions  serve  as  strong  starting  points  for  our  discussion  and,  as  we 
will  see  later,  provide  the  framework  for  defining  the  program  within  this  thesis  as  an 
agent. 

Despite  the  fact  that  there  are  many  ways  in  which  software  agents  have  been 
defined,  virtually  all  scholars  agree  that  agents  to  some  extent  share  three  common 
characteristics.  The  first  of  these  characteristics  is  a  means  by  which  the  agent  can 
receive  stimulus  from,  or  sense  changes  in,  the  environment.  This  serves  as  a  source  of 
input  for  the  software  entity  and  allows  it  to  receive  information  for  processing  or 
prompting  from  its  surroundings.  The  second  characteristic  that  most  agents  possess  is 
the  presence  of  some  sort  of  internal  environment.  This  is  a  very  general  definition  of 
whatever  rules  or  methods  govern  the  actions  of  the  agent.  This  is  what  defines  how  the 
agent  will  process  stimuli  and  how  it  will  determine  what  the  appropriate  response  is 
within  its  environment.  The  final  common  characteristic  is  the  means  by  which  the  agent 
acts  upon  the  environment.  Once  an  agent  receives  information  or  stimulus  and  decides 
what  course  of  action  to  take,  if  any,  is  how  it  influences  and  acts  upon  its  environment. 
These  three  components  can  be  summarized  as  an  input  mechanism,  an  evaluation 
process,  and  output  mechanism.  The  evaluation  process  characteristic,  or  the  internal 
environment  of  the  agent,  will  be  discussed  further  in  the  following  section  of  this 
chapter. 
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B,  TYPES  OF  AGENTS 

There  are  two  main,  general  eategories  of  software  agents.  What  separates  these 
eategories  from  each  other  is  the  complexity  of  the  internal  structure  of  the  agent.  In 
reactive  agents  the  internal  structure  of  the  agent  is  relatively  simple,  while  in  a  cognitive 
agent  more  complex  processes  are  incorporated. 

1.  Reactive  Agents 

This  type  of  entity  is  the  most  basic  form  of  the  software  agent.  As  the  name 
implies,  reactive  agents  are  designed  to  perform  specific,  simple  actions  as  a  result  of 
interaction  with  their  environment.  In  most  cases,  these  actions  are  triggered  by  key 
events,  after  which  the  agent  uses  a  simple  set  of  rules  to  determine  the  proper  response. 
A  stimulus  is  applied  to  the  software  agent  and  a  predictable,  foreseeable  reply  or 
reaction  occurs.  This  response  is  a  regular  occurrence  that  will  always  be  the  same  for  a 
specific  causation. 

The  internal  structure  for  this  type  of  agent  is  usually  a  set  of  rules  or  a  list  of 
actions.  As  a  stimulus  condition  is  met  or  an  event  occurs,  the  agent  processes  the  action 
by  running  through  this  list  of  rules.  The  agent  then  uses  a  specific  rule  to  determine  the 
appropriate  response,  if  any  apply.  If  none  of  the  rules  apply  or  the  necessary  conditions 
are  not  met,  then  the  agent  may  perform  some  sort  of  a  default  action,  or  take  no  action  at 
all. 

An  example  of  a  reactive  agent  would  be  a  simple  solution  of  the  El  Farol 
programming  problem.  In  1994,  Brian  Arthur  introduced  a  programming  problem  that 
consisted  of  trying  to  model  the  decision  process  of  a  patron  deciding  whether  or  not  to 
spend  an  evening  at  the  El  Earol  Bar  in  Santa  Ee,  New  Mexico  (Arthur,  1994). 
Essentially,  the  problem  statement  consisted  of  a  bar  whose  patrons  were  happiest  when 
an  optimal  occupancy  was  achieved.  Eor  example,  if  the  ideal  occupancy  of  the  El  Earol 
were  60  people,  the  patrons  would  be  unhappy  if  they  arrived  to  find  100  people 
crammed  into  the  small  tavern.  Eikewise,  customers  would  be  unhappy  if  they  did  not  go 
to  the  El  Earol  for  an  evening  of  entertainment,  and  then  discovered  that  only  30  people 
had  been  present  at  the  bar.  In  this  second  case,  the  patron  could  have  easily  gone  to  the 
bar  and  had  plenty  of  room  to  be  comfortable.  A  reactive  agent  would  only  focus  on 

comparing  the  actual  attendance  with  the  ideal  attendance  and  would  use  a  simple  rule,  or 

10 


set  of  rules,  when  deeiding  whether  or  not  to  attend.  For  example,  a  reaetive  patron  agent 
eould  be  keeping  track  of  the  weekly  attendance  at  the  El  Farol  for  the  last  five  weeks.  If 
the  average  attendance  for  the  bar  during  these  weeks  were  70  people,  the  agent  would 
use  a  simple  comparative  rule  to  “decide”  to  not  go  to  the  El  Earol  this  week.  An  obvious 
limitation  of  this  type  of  simple  solution  to  this  problem  is  that  the  agent  is  not  very 
flexible  in  responding  to  external  stimulus.  The  response  is  determined  beforehand  by  a 
rigid  set  of  rules  that  would  apply  in  exactly  the  same  way  in  every  similar  instance. 

2,  Cognitive  Agents 

This  type  of  entity  is  a  much  more  advanced  form  of  software  agent.  Cognitive 
agents  are,  by  their  nature,  designed  to  model  more  complex  objects  than  reactive  agents. 
These  pieces  of  software  model  the  decision  making  process  by  attempting  to  model 
cognitive  thinking.  These  types  of  agents  react  to  their  environments  in  a  more  versatile 
manner,  and  a  specific  stimulus  may  result  in  different  responses  depending  on  the 
context  of  the  initiating  events. 

The  internal  structure  for  this  type  of  agent  is  usually  centered  on  a  system  of 
goals.  These  goals,  or  sets  of  goals,  are  designed  to  model  the  purpose  or  intent  of  the 
modeled  object.  It  is  essential  to  cognitive  agents  that  there  be  some  sort  of  objective  that 
the  entity  is  trying  to  achieve.  Along  with  this,  the  agent  is  also  designed  with  a 
measurement  system  of  some  kind.  This  measurement  allows  the  agent  to  evaluate  the 
progress  it  is  making  toward  achieving  those  goals.  It  also  allows  the  agent  to  weigh 
goals  against  each  other  and  to  possibly  choose  between  actions  in  order  to  resolve 
conflicts  between  opposing  goals. 

An  example  of  cognitive  agents  would  be  software  designed  to  model  some  of  the 
properties  of  a  bird.  In  1987,  Craig  Reynolds  designed  a  programming  problem  that  tried 
to  emulate  some  of  the  characteristics  of  animal  flocks,  herds,  and  schools  (Reynolds, 
1987).  Since  Reynolds  worked  on  this  program  while  in  New  York  and  applied  it  to 
flocks  of  birds,  the  problem  became  affectionately  known  as  the  “Boids”  problem 
(pronounce  “birds”  with  a  Brooklyn  accent).  Though  this  problem  can  take  many  forms, 
a  common  one  consists  of  designing  bird  objects  that  have  several  goals  and  makes 
decisions  based  on  the  urgency  of  achieving  those  goals.  An  example  of  this  may  consist 

of  programming  ‘Boids  that  have  three  main  goals.  Flocking,  Circulating,  and  Collision 
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Avoidance.  The  floeking  goal  would  drive  the  ‘Boid  to  seek  out  and  gather  with  other 
‘Boids  so  it  would  not  expire  from  loneliness.  The  Circulating  goal  would  prevent  the 
‘Bold  from  flying  around  in  eireles  so  it  would  eneounter  new  seenery  and  would  not  die 
from  boredom.  The  Collision  Avoidance  goal  would,  obviously,  be  designed  to  prevent 
the  ‘Boid  from  hitting  obstaeles  and  injuring  or  killing  itself  The  measurement  or 
evaluation  of  these  goals  would  then  allow  the  ‘Boid  to  determine  whieh  goal  was  most 
urgent,  and  make  deeisions  aeeordingly.  For  example,  if  a  ‘Boid  was  flying  in  a  floek 
while  aehieving  good  eireulation  it  would  be  satisfying  two  out  of  three  goals.  If  the  floek 
turned  toward  an  obstaele,  however,  the  Collision  Avoidanee  goal  would  beeome  more 
eritieal  as  progress  toward  that  obstruction  continued.  At  some  point,  that  ‘Boid  would 
have  a  deeision  to  make.  On  one  hand  it  would  have  the  eritieality  of  satisfying  the 
Floeking  goal  by  staying  with  the  other  ‘Boids  despite  their  impending  doom.  On  the 
other,  it  would  have  satisfying  the  Collision  Avoidanee  goal  by  turning  away  from  the 
obstaele  and  possibly  separating  itself  from  the  group.  In  this  way,  simple  eognitive 
objeets  are  ereated  and  then  turned  loose  to  internet  with  the  environment  and  make 
independent  deeisions. 

Extending  the  definition  of  the  eognitive  agent  eould  inelude  the  use  of 
programming  tools  sueh  as  genetie  algorithms.  This  type  of  eneoding  would  allow  eertain 
traits  to  be  passed  on  to  different  generations  of  software  agents,  and  allow  an  agent 
population  to  evolve  and  refine  itself.  Certain  traits  or  dispositions  eould  be  programmed 
into  various  versions  of  a  similar  agent,  or  be  allowed  to  develop  during  a  breeding  cyele. 
For  example,  a  ‘Boid  eould  eontain  a  genetie  value  that  determined  how  elose  it  would 
eome  to  an  obstruction  before  turning.  We  eould  also  program  our  environment  so  that 
the  ‘Boids  would  breed  with  a  partner  every  100  movements,  produee  two  offspring,  and 
then  die.  The  resulting  “closeness”  value  for  the  offspring  would  be  an  average  of  the  two 
parents.  It  is  very  likely  that  in  this  ease,  after  a  eertain  number  of  generations,  low 
“eloseness”  values  would  be  eompletely  bred  out  of  the  population.  ‘Boids  that  got  too 
elose  to  objeets  before  turning  would  eventually  keep  eolliding  and  dying  and,  thus,  be 
eliminated  from  the  genetie  pool. 
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C.  WHY  USE  AGENTS? 

Software  agents  are  programmed  entities  that  are  uniquely  suited  for  effeetive 
employment  in  the  examination  of  meteorologieal  data.  As  Dr.  Jens  Pohl  noted  in  his 
paper  on  applying  eontext  to  create  information  (Pohl,  Transitioning  from  Data  to 
Information),  we  are  in  an  age  where  users  can  be  overwhelmed  by  the  vast  amount  of 
available  data.  This  description  accurately  encompasses  the  enormous  amount  of 
meteorological  numeric  model  output  that  METOC  professionals  have  available  to  them. 
Software  agents  are  extremely  well  suited  for  sorting  through  this  kind  of  output  using 
either  reactive  or  cognitive  processing  methods.  Reactive  agents  could  handle 
considerable  quantities  of  model  output  and  perform  tasks  as  simple  as  highlighting 
locations  where  wind  speeds  exceeded  a  certain  value.  This  capability  is  currently 
available  in  METOC  data  retrieval  and  assessment  software,  but  agents  could  build 
greatly  upon  this  utility  in  many  ways.  Given  a  list  of  platforms  that  are  to  be  used  during 
an  exercise,  reactive  agents  could  also  compare  forecasted  conditions  with  operational 
thresholds.  Cognitive  agents  could  extend  these  benefits  by  applying  several  goals  to 
model  output  processing.  In  a  more  advanced  iteration,  these  kinds  of  agents  could  use 
genetic  algorithms  and  model  verification  to  track  which  models  are  most  accurate  in 
certain  geographic  regions.  They  could  then  produce  composite  forecasts  by  combining 
portions  of  different  model  forecasts.  This  possibility  becomes  especially  significant 
when  considering  the  speed  and  relative  ease  that  software  agents  would  be  able  to 
process  vast  amounts  of  data. 

In  and  of  itself,  raw  data  is  rarely  significant  to  the  warfighter.  Dr.  Pohl  stated  in 
the  above  mentioned  article  that  transforming  data  into  information  and  knowledge  that 
can  be  leveraged  as  an  asset  by  the  user  is  where  the  true  power  of  computing  can  have 
the  greatest  impact.  Initially,  this  procedure  would  begin  as  the  simple  loading  and 
processing  of  data  according  to  a  set  of  predefined,  user-entered  rules.  In  theory, 
depending  on  the  complexity  of  the  agent’s  data  manipulation  rules,  these  software 
entities  could  eventually  begin  to  find  relations  between  various  pieces  of  data.  As  these 
relations  are  recognized  and  developed,  context  is  created  and  the  data  becomes 
information.  Dr.  Pohl  presented  the  use  of  ontologies  to  create  this  context,  but  a 
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carefully  crafted  reactive  or  cognitive  agent  eould  perform  a  similar  funetion  and  produee 
similar  results  that  would  be  signifieant  to  an  educated  user. 

D,  APPLYING  AGENTS  TO  THIS  THESIS 

In  the  spirit  of  learning  to  walk  before  trying  to  run,  reactive  agents  are  examined 
within  this  thesis.  The  agent  that  will  be  developed  will  serve  as  a  link  between  numerie 
model  output  and  command  and  control  software  and  will  be  referred  to  in  this  paper  as 
the  Java  Version  Weather  Agent,  or  WAg  for  short.  The  next  ehapter  will  detail  the 
command  and  control  tool  that  will  be  examined  and  used  as  a  sample  platform  from 
which  to  develop  the  requirements  for  this  agent.  The  WAg  itself  will  be  outlined  and  it’s 
development  detailed  in  the  fourth  chapter. 

Though  not  eoded  or  applied  to  researeh  direetly  here,  eognitive  agents  and  the 
use  of  ontologies  to  automatically  produce  meteorological  information  and  knowledge 
from  numeric  model  output  bears  consideration  as  well.  This  topic  will  be  discussed  as 
appropriate  within  this  thesis. 
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III.  SEAWAY 


A.  WHAT  IS  SEAWAY? 

The  SEAWAY  program  is  a  project  developed  by  CDM  Technologies,  Inc  of  San 
Luis  Obispo.  CDM  Technologies  began  as  an  offshoot  of  a  student  research  lab  within 
the  Computer  Science  Department  of  the  California  Polytechnic  University.  As  this  group 
began  to  pursue  research  into  expert-agent  software,  specifically  incorporating  the 
application  of  ontologies,  interest  in  producing  decision-aid  tools  using  this  technology 
began  to  develop.  This  group  started  to  program  software  agent  solutions  for  both 
government  and  commercial  organizations.  As  finished  products  were  fielded,  it  became 
clear  that  providing  adequate  follow-up  support  for  this  software  was  a  sizeable 
commitment  that  surpassed  the  resources  of  a  student-staffed  group.  This  led  to  the 
creation  of  CDM  Technologies,  which  still  has  strong  ties  to  Cal  Poly  through  former 
students  and  interaction  with  faculty  such  as  Dr.  Jens  Pohl.  CDM  describes  itself  as 
specializing  in  developing  “decision-support  tools  that  promote  effective  planning  and 
coordination  of  complex  logistic  operations”  using  “expert-agent  technology”.  This 
chapter  will  be  a  general  introduction  for  the  reader  into  the  capabilities  of  SEAWAY, 
and  is  not  intended  to  serve  as  a  user  guide  for  the  program  or  provide  the  specific  detail 
that  is  commonly  known  as  ‘buttonology”. 

According  to  its  sales  brochure,  SEAWAY  is  CDM’s  “latest  decision-support 
system  designed  to  satisfy  the  focused  logistic  demand  of  Joint  Vision  2020”.  It  also 
defines  SEAWAY  as  a,  “joint  decision-support  system  for  sea  base  logistics  planning  and 
coordination”.  This  program  is  essentially  a  command  and  control  software  tool  funded 
primarily  by  the  Marine  Corps  and  developed  to  support  logistics  operations  and  track 
requirements.  CDM  advertises  three  main  support  areas  that  this  software  is  specialized 
for.  The  first  of  these  is  to  assist  in  Cargo  Visibility.  This  essentially  consists  of  taking  all 
logistical  assets  within  a  theatre,  and  making  them  visible  to  high-level  planners.  A 
second  mission  area  is  Cargo  Operations.  In  support  of  this,  SEAWAY  can  tell  it’s  user 
on  what  ship,  and  in  which  hold,  an  exact  supply  component  lies.  This  allows  for  detailed 
tracking  of  precisely  where  replacement  parts  or  supplies  are  located.  The  third  mission 

area  SEAWAY  supports  is  Mission  Planning.  In  this  respect,  the  software  develops  and 
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updates  offload  plans  that  commanders  can  use  to  project  the  logistical  requirements  of 
ashore  units.  The  expert  agents  within  the  program  predict  the  requirements  of  employed 
units  based  on  their  particular  scheme  of  maneuver.  A  fourth  mission  area  is  Mission 
Tracking,  which  allows  the  user  to  see  continuous  updates  of  mission  status  and  logistical 
standing  during  an  operation.  The  final  mission  that  SEAWAY  was  designed  to  support 
was  Mission  Execution.  In  this  regard,  the  versatility  of  this  program  allows  commanders 
to  examine  various  execution  options  as  the  mission  is  underway  and  unfolds.  By 
providing  mission  support  for  the  aforementioned  five  areas  SEAWAY  establishes  itself 
as  a  powerful  planning  tool  for  warfare  commanders,  which  is  one  of  the  reasons  it  was 
chosen  for  use  along  with  the  development  of  the  WAg. 

The  overall  SEAWAY  program  actually  consists  of  three  main  components,  the 
server,  the  agents,  and  the  client.  The  server  acts  as  a  means  to  load  or  save  archived 
information  and  define  the  paths  that  the  program  will  use  to  access  information.  It  can 
initialize  the  SEAWAY  program  so  that  users  will  have  access  to  either  previously 
defined  areas  and  scenarios  or  the  default  data.  The  agent  element  of  this  program 
coordinates  and  manages  the  interaction  and  initialization  of  the  different  kind  of  agents 
that  SEAWAY  uses.  The  types  of  agents  this  program  incorporates  are  requirements, 
delivery,  inventory,  weather,  movement,  route,  tactics,  and  siting.  It  is  important  to  point 
out  here  that  even  though  SEAWAY  already  has  an  existing  weather  agent,  the  agent  this 
thesis  is  researching  is  different  for  significant  reasons.  SEAWAY  uses  its  weather  agent 
as  a  means  of  evaluating  how  a  forecast  will  impact  a  programmed  logistics  delivery 
route.  At  this  point,  however,  the  program  requires  the  user  to  enter  the  weather 
parameters  by  hand  before  any  kind  of  evaluation  can  be  made.  The  WAg  is  intended  to 
automatically  produce  forecast  arrays  directly  from  numeric  model  output,  which  would 
provide  utility  for  this  information  to  be  imported  directly  into  command  and  control 
software  such  as  SEAWAY.  The  user  interfaces  with  SEAWAY  through  the  client 
portion  of  the  program.  This  is  the  window  that  displays  the  operation  area  maps  and 
provides  access  to  all  of  the  program  menus.  This  is  what  a  typical  user  will  think  of 
when  asked  about  this  program.  The  three  main  components  of  SEAWAY  are  all 
important,  but  in  particular  the  agent  element  provides  special  utility  that  will  be  further 
examined  in  the  next  section  of  this  chapter. 
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B,  WHY  USE  SEAWAY? 

The  CDM  Technologies  program  SEAWAY  has  several  features  that  make  it  well 
suited  for  interaction  with  a  military  agent  in  general,  and  this  planned  WAg  in  particular. 
A  basic  characteristic  of  this  program  is  that  it  is  coded  in  the  computer  language  Java.  In 
general,  this  is  a  versatile  language  since  it  is  largely  platform  independent,  meaning  that 
it  can  run  on  any  kind  of  platform  as  long  as  it  is  loaded  with  the  latest  version  of  the  Java 
Virtual  Machine  (JVM).  The  WAg  this  thesis  is  researching  is  programmed  in  Java  as 
well,  which  is  convenient  since  it  minimizes  and  problems  that  may  have  developed  due 
to  language-specific  differences.  In  general  SEAWAY  is  also  a  good  program  for 
military  use  since  it  imports  military  standard  maps.  The  software  displays  and  allows 
notation  on  National  Geospatial-Intelligence  Agency  (NGA)  maps.  This  is  a  desirable 
feature  since  military  operation  might  be  planned  using  a  similar  map  or  standard.  In 
addition,  this  program  can  also  import  digital  terrain  elevation  data  (DTED)  maps, 
although  these  are  generally  not  preferred  due  to  the  excessively  large  size  of  these  files. 
There  are  several  other  reasons  that  SEAWAY  was  examined  in  conjunction  with  the 
development  of  the  WAg  that  will  be  detailed  in  the  next  chapters. 

In  the  previous  section  it  was  mentioned  that  the  SEAWAY  agent  element  would 
be  revisited  in  more  detail.  This  component  of  the  software,  which  manages  the 
program’s  agents,  is  actually  a  key  feature  that  facilitates  the  incorporation  of  the  WAg. 
This  allows  the  program  to  create  an  instance  of  the  WAg  and  all  of  its  components. 
SEAWAY  then  also  has  access  that  enables  it  to  instantiate  the  request  and  forecast 
objects  that  are  a  part  of  the  WAg.  This  permits  the  direct  exchange  of  information  and 
avoids  other  more  complex  methods  of  passing  information  to  and  from  SEAWAY. 
Without  this  type  of  utility,  exchanges  of  data  would  have  to  use  a  complex  application 
programming  interface  (API)  and  proxy  object  wrappers.  The  agent  feature  of  SEAWAY 
greatly  simplifies  the  integration  of  the  WAg  with  this  program. 

Another  characteristic  of  SEAWAY  that  makes  it  a  good  choice  for  use  with  this 
thesis  is  that  it  already  incorporates  some  consideration  of  environmental  factors.  This 
software  was  designed  from  the  beginning  to  consider  all  aspects  of  logistics,  including 
factors  that  could  impact  the  delivery  of  supplies  such  as  hazardous  weather.  As  a  result, 

SEAWAY  comes  complete  with  weather  symbology  that  can  be  displayed  on  the  NGA 
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maps.  Additionally,  this  program  can  also  evaluate  the  impact  that  specific  weather 
parameters  will  have  on  logistic  delivery  routes.  This  leaves  the  WAg  free  to  focus  on  the 
speeific  problem  of  producing  and  providing  forecast  information  from  model  output.  All 
of  the  eharacteristics  mentioned  within  this  chapter  make  SEAWAY  a  good  choiee  for 
use  when  examining  the  proof-of-eoneept  ereation  of  a  WAg  program. 
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IV.  THE  WEATHER  AGENT  (WAG) 


A.  THE  PURPOSE 

One  of  the  main  reasons  the  eoneept  of  a  WAg  was  ehosen  for  examination  within 
this  thesis  was  to  evaluate  its  feasibility  as  an  element  of  FORCEnet.  Two  of  the  tenants 
of  FORCEnet  are  that  government  teehnology,  speeifieally  teehnology  used  within  the 
Department  of  Defense  (DOD),  should  be  independent  of  “stovepipes”  and  utilize  web 
serviees.  The  use  of  agent-based  software  is  a  good  ehoiee  to  meet  both  of  these 
provisions,  and  ean  be  a  resouree  the  METOC  Community  ean  implement  in  order  to 
transform  the  means  by  which  it  provides  service  to  its  customers. 

A  “stovepipe”  is  an  organizational  configuration  that  bears  a  visual  resemblance 
to  its  namesake  due  to  an  inherently  restrictive  scope  that  serves  only  to  meet  a  specific 
need.  This  term  is  most  commonly  applied  to  command  structures  that  are  narrow,  and 
only  support  communication  between  junior  and  senior  components.  While  this  may 
facilitate  the  flow  of  information  up  and  down  the  chain-of-command,  it  restricts  lateral 
movement  and  the  sharing  of  ideas  between  component  commands  within  the 
organization.  This  view  can  be  applied  to  naval  communities,  the  branches  of  military 
service,  or  to  branches  of  government  service.  This  kind  of  restrictive  organizational 
structure  is  also  a  problem  when  considering  how  technology  is  employed  within  the 
DOD.  When  an  individual  member  within  the  Department  takes  steps  to  meet  a 
technological  need  it  is  often  done  by  contracting  a  commercial  agency  to  develop  a 
specific  piece  of  software  utilizing  proprietary  knowledge.  This  creates  a  problem  since 
that  proprietary  knowledge  often  cannot  be  shared  between  commercial  sources  and,  as  a 
result,  the  various  ensuing  products  are  then  not  compatible. 

Agent-based  technology  can  help  rectify  this  situation  by  encouraging  the 
production  of  common  architecture  software  that  is  produced  in  accordance  with  a 
specific  standard.  For  example,  the  WAg  is  programmed  in  the  platform  independent 
language  Java,  is  intended  to  be  an  open  source  product,  and  will  serve  as  a  bridge 
between  a  government  produced  numeric  model  and  a  privately  licensed  command  and 
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control  tool.  Until  an  ideal  FORCEnet  operating  environment  is  aehieved,  agents  ean  be 
utilized  in  this  way  to  breakdown  teehnologieal  “stovepipes”  and  beeome  a  means  of 
enabling  interoperability. 

The  web  serviees  aspeet  of  FORCEnet  would  enable  teehnologieal  assets  to 
remain  distributed,  even  forward  deployed,  but  still  eapable  of  reaehing  baek  for  support 
on  an  as-needed  basis.  A  foeus  on  providing  support  via  web  serviees  has  the  potential  to 
allow  DOD  eustomers  aeeess  to  information  at  any  time.  For  example,  if  a  naval 
Commander  Amphibious  Task  Foree  (CATF)  and  marine  Commander  Fanding  Foree 
(CFF)  were  eoordinating  to  plan  an  amphibious  landing,  eurrent  weather  information 
would  be  vital  to  safe  and  effeetive  operations.  Fully  integrated  FORCEnet  eonneetivity 
would  allow  these  eommanders  to  reaeh  baek  to  the  nearest  METOC  Center  and 
download  this  information  as  required.  Moreover,  a  full  and  eomplete  implementation  of 
FORCEnet  would  keep  providing  updates  of  that  environmental  information  as  it  beeame 
available  and  would  allow  full  integration  with  display  eapabilities.  This  would  make  it 
possible  to  projeet  that  weather  data  within  whatever  planning  tool  was  already  in  use. 
Agent-based  software  is  a  programming  methodology  that  eould  enable  exaetly  this  type 
of  support.  Aside  from  breaking  down  teehnologieal  stovepipes,  as  mentioned  in  the 
previous  ehapter,  programmed  agents  ean  be  implemented  to  take  advantage  of  this  type 
of  web  serviee  support. 

As  an  example,  the  WAg  allows  users  of  SEAWAY  to  request  weather 
information  via  a  loeal  agent  with  the  push  of  a  virtual  button.  The  WAg  then  uses  an 
Internet  eonneetion  to  eontaet  servers  at  a  weather  eenter,  in  this  ease  Fleet  Numerical 
Meteorology  and  Oeeanography  (FNMOC),  and  utilize  available  web  serviees.  These 
same  agents  eould  be  set  so  that  they  would  eontinue  to  poll  the  FNMOC  servers  at  a  set 
interval  based  on  model  runtimes  to  ensure  that  the  delivered  data  remained  updated.  In 
other  eases,  software  agents  on  FNMOC ’s  servers  eould  likewise  push  data  to  various 
eustomers  at  set  intervals  depending  on  the  type  of  request.  Agent-based  software  eould 
be  a  reliable  means  of  implementing  the  web  serviees  tenant  of  FORCEnet. 

B,  AGENT  REQUIREMENTS 

Before  beginning  to  design  the  WAg  it  is  important  to  elearly  define  what  will  be 
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will  be,  we  have  a  set  of  goals  to  work  towards  and  a  yardstick  by  which  to  measure  the 
success  of  this  effort.  In  software  development  there  are  two  kinds  of  requirements, 
functional  and  non-functional.  In  his  book  on  software  engineering,  Stephen  Schach 
(Schach,  2002)  defined  these  two  classifications  in  the  following  way,  “Functional 
requirements  relate  to  the  functionality  of  the  target  software... Non- functional 
specifications  specify  properties  of  the  target  software,  such  as  reliability  and 
maintainability,  or  relate  to  the  environment  in  which  the  software  must  run”.  A  useful 
exercise  would  be  to  consider  the  types  of  requirements  you  would  be  concerned  with  if 
you  were  constructing  a  deck  for  your  home.  A  functional  requirement  would  be 
specifying  the  use  of  three-quarter  inch  bolts  to  fasten  the  joints.  A  non-functional 
requirement  would  be  stating  that  the  deck  should  be  weatherproofed  so  it  can  withstand 
wear  and  tear  from  rain  and  sun.  This  section  will  break  down  the  requirements  for  the 
WAg  into  these  two  categories. 

1.  Functional  Requirements 

The  first  major  functional  requirement  that  had  to  be  defined  was  the  types  of 
meteorological  or  oceanographic  products  the  WAg  would  process  for  SEAWAY.  As 
previously  mentioned,  the  designers  of  SEAWAY  had  built  certain  environmental 
parameters  into  their  software.  In  their  design  process  they  used  an  unclassified  Navy 
weather  forecast  and,  as  a  result,  had  incorporated  parameters  such  as  sea  state,  winds, 
etc.  Since  this  thesis  was  intended  to  be  a  proof  of  concept  attempt  at  implementing  agent 
technology  in  this  manner,  it  was  important  to  have  a  scope  suitable  for  an  initial  effort. 
Thus,  it  was  determined  that  the  agent  would  only  be  required  to  return  a  few  forecast 
parameters  vital  to  surface  operations  within  a  littoral  environment.  This  information 
would  include  surface  winds,  significant  wave  height,  and  12-hour  precipitation  amounts. 
In  addition,  surface  wind  would  be  further  defined  as  the  wind  1 0  meters  above  ground 
level.  These  were  also  convenient  choices  for  forecast  parameters  are  easily  accessible 
from  most  meteorological  or  oceanographic  numerical  models  in  a  gridded  format. 

The  second  major  functional  requirement  that  had  to  be  defined  was  which 
numerical  model  would  be  used  as  the  source  for  downloading  this  gridded  output.  Since 
this  is  a  thesis  being  researched  at  a  military  learning  institution,  it  was  easy  to  decide  to 
use  models  developed  by  the  Naval  Research  Eaboratory  (NRL)  and  National  Oceanic 
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and  Atmospheric  Administration  (NOAA).  These  models  are  in  wide  use  within  the 
Navy,  and  the  author  had  practical  forecasting  experience  with  them  as  well.  Considering 
that  this  project  would  focus  on  wind  output,  12-hour  precipitation  amounts,  and 
significant  wave  height,  the  Coupled  Ocean/Atmosphere  Mesoscale  Prediction  System 
(COAMPS)  and  the  Wave  Analysis  Model  (WAM)  seemed  to  be  reasonable  selections. 
As  the  name  implies,  COAMPS  is  a  coupled  air/ocean  model.  The  website  of  FNMOC 
describes  it  as  a  model  that  runs  in  a  continuous  update  cycle  and  gets  its  initial  fields 
from  the  Navy  Operational  Global  Atmospheric  Prediction  System  (NOGAPS)  model 
grids  using  real  and  synthetic  observations.  It  calculates  wind  components,  potential 
temperature,  mixing  ratio,  surface  pressure,  ground  temperature,  ground  wetness,  and  sea 
surface  temperature.  The  grids  are  latitude-longitude  or  Cartesian  coordinates  on  a 
horizontal  map  projection  and  can  calculate  parameters  for  up  to  30  staggered  vertical 
levels.  It  incorporates  I -kilometer  database  topography  from  the  Defense  Mapping 
Agency  level  1  DTED,  which  can  significantly  impact  near  surface  parameters.  WAM  is 
a  global  model  that  produces  1 -degree  resolution  gridded  output  for  various  oceanic 
parameters.  These  include  significant  wave  height,  mean  wave  direction  and  period, 
secondary  wave  direction,  secondary  wave  mean  period,  whitecap  probability,  and 
maximum  wave  height  as  well  as  direction,  height,  period  for  both  seas  and  swell. 

After  deciding  which  parameters  and  models  the  agent  would  utilize,  it  was 
important  to  decide  what  data  service  the  WAg  would  use.  FNMOC  runs  several  data 
servers  and  subscription  services  that  include  the  Tactical  Environmental  Data  Server,  the 
Metcast  server,  and  the  newly  developed  Data  Blade  server.  For  the  sake  of  simplicity, 
the  Metcast  server  was  chosen  for  use.  This  was  also  chosen  due  to  the  author’s 
familiarity  with  the  request  procedure  for  this  service.  It  is  important  to  note,  however, 
that  conceptually  the  architecture  of  the  WAg  can  be  applied  for  use  with  any  data 
service.  This  flexibility  is  one  of  the  major  strengths  of  implementing  agent-based 
technology,  and  highlights  the  versatility  and  future  potential  of  this  thesis  topic.  TEDS 
services  or  the  Data  Blade  could  both  be  utilized  by  the  WAg  in  future  iteration  of  this 
project.  According  to  the  Metnet  homepage.  Metcast  is  a  subscription  service  that  runs  on 
an  application  server.  It  receives  requests  via  hypertext  transfer  protocol  (http)  or 
hypertext  transfer  protocol  secure  (https)  that  are  formatted  in  the  Metcast  request 
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language,  MBL.  It  can  return  gridded,  observational,  imagery,  or  text  products.  Metcast 
provides  access  to  the  COAPMS  and  WAM  model  output  required  for  use  by  this  agent. 
Even  this  basic  description  highlights  how  Metcast  meets  many  of  the  service 
requirements  of  the  WAg. 

Another  functional  requirement  that  had  to  be  decided  before  beginning  the 
production  of  this  software  was  how  information  would  be  passed  between  the  agent  and 
SEAWAY.  Since  the  SEAWAY  program  could  create  a  local  instance  of  the  WAg,  this 
decision  boiled  down  to  the  preferences  of  the  SEAWAY  developers  for  the  forecast 
parameters.  During  an  initial  discussion  it  was  mentioned  that  within  their  program  they 
would  be  converting  many  of  the  internally  held  values  to  parsed  integers,  to  include 
latitude  and  longitudes.  Wind  speeds  and  direction,  significant  wave  height,  and 
precipitation  amounts  can  all  be  adequately  represented  using  such  integers.  These  three 
values  would  then  be  combined  in  individual  arrays  with  their  corresponding  geographic 
locations. 

2,  Non-Functional  Requirements 

A  major  non- functional  requirement  for  this  software  is  that  its  development  be 
grounded  in  common  standard  architectures.  As  previously  stated,  this  would  prevent  the 
agent  from  being  dependent  on  proprietary  information  that  might  restrict  its  ability  to 
interact  with  other  pieces  of  software.  As  an  example,  this  would  include  being  able  to 
request  and  receive  information  via  http  or  https.  This  is  the  protocol  used  to  transfer 
information  across  the  Internet  and  is  internationally  recognized.  The  software  should  be 
platform  independent  and  be  able  to  run  on  any  type  of  operating  system.  This  was  also 
previously  discussed  in  this  chapter  as  the  reason  it  was  programmed  in  the  Java  language 
developed  by  Sun  Microsystems.  In  general,  this  software  would  be  designed  in 
compliance  with  the  guidance  provided  by  the  International  Organization  for 
Standardization  (ISO).  The  ISO  is  an  international  organization  whose  purpose  is  to 
standardize  software -programming  guidelines  in  an  effort  to  ensure  interoperability 
between  computing  systems. 

The  size  of  the  agent  and  the  delivered  data  are  also  worth  considering  as  a  non¬ 
functional  requirement.  Since  this  agent  is  intended  to  be  a  portable  part  of  a  distributed 

system,  the  size  of  the  WAg  itself  must  be  kept  manageable.  If  the  agent  became  too 
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large  or  unwieldy,  it  might  interfere  with  the  command  and  control  software  it  interacts 
with.  This  kind  of  effect  would  be  contrary  to  the  benefits  the  agent  would  provide  to  the 
user.  The  size  of  the  downloaded  gridded  output  must  also  be  kept  manageable  and 
within  reason.  Since  much  of  the  operational  planning  that  occurs  takes  place  in  forward 
deployed  locations,  available  bandwidth  must  be  viewed  as  a  valuable  commodity.  In 
many  areas  Internet  access  is  inconsistent  and  bandwidth-limited,  which  would  prevent 
the  transfer  of  large  files  to  and  from  the  WAg.  This  will  be  discussed  further  in  the 
following  section,  but  was  kept  in  mind  when  writing  the  program  code. 

C.  THE  AGENT  STRUCTURE 

There  were  several  different  ways  to  structure  the  agent  that  were  considered 
when  writing  this  software.  It  was  important  to  evaluate  how  the  agent  would  be 
configured  internally,  as  well  as  how  it  would  be  placed  within  its  environment.  As  we 
will  see,  how  the  system  was  structured  would  have  positive  and  negative  implications 
that  had  to  be  considered  during  development.  As  a  beginning  point,  however,  the 
commonly  accepted  general  structure  of  agents  was  useful  in  deciding  how  to  begin 
defining  the  architecture  of  the  WAg  itself,  prior  to  placing  it  within  an  environment. 

The  basic  definition  of  an  agent  is  as  a  software  entity  that  has  an  input,  an  output, 
and  some  sort  of  an  internal  environment.  This  simple  description  establishes  a  means  by 
which  we  can  begin  to  structure  the  WAg.  Since  the  agent  would  be  handling  requests 
from  the  planning  software  for  forecast  parameters,  this  obviously  becomes  the  input  for 
the  software.  In  order  to  produce  forecast  information  we  must  provide  the  Metcast  server 
with  several  pieces  of  information.  These  include  the  latitude-longitude  bounding  box, 
the  desired  timeframe,  and  the  specified  desired  environmental  parameters  (which  in  our 
case  has  already  been  determined  to  be  surface  wind,  significant  wave  height,  and 
precipitation  amounts).  These  items  can  be  grouped  by  considering  them  as  items  that 
together  compose  a  request.  In  turn,  this  request  can  be  instantiated  within  the  Java 
environment  as  a  software  object  that  has  attributes  that  correspond  to  the  grouped  items. 
Other  attributes  that  may  be  significant  are  the  assignment  of  a  request  identification 
number,  the  assignment  of  a  forecast  number,  a  binary  value  that  indicates  whether  or  not 
the  request  has  been  fulfilled,  and  some  sort  of  value  that  denotes  the  desired  granularity 
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or  resolution  of  the  model.  In  this  way  the  idea  of  a  request  object,  that  can  be  understood 
by  the  agent  and  will  be  created  by  the  planning  software,  is  formed. 

Since  the  agent  will  be  returning  a  forecast  to  the  command  and  control  tool,  this 
becomes  the  obvious  choice  for  the  output  of  the  software.  In  the  case  of  this  thesis, 
where  we  are  only  investigating  feasibility  via  the  processing  of  selected  parameters,  this 
object  is  simplified  considerably.  In  order  to  track  the  returned  or  issued  forecasts  it  is 
reasonable  to  include  some  sort  of  identification  number  as  an  attribute  of  the  forecast 
object.  Aside  from  this,  the  forecast  object  must  also  contain  the  forecasted  parameters. 
In  the  case  of  surface  winds,  for  example,  this  particular  attribute  will  consist  of  an  array 
of  values.  From  the  requirements  we  see  that  these  will  be  parsed  integer  values  for  the 
latitude  and  longitude,  and  integer  values  for  the  wind  speed  and  direction.  Together, 
these  items  would  compose  the  output  of  the  WAg. 

The  internal  environment  of  the  agent  is  composed  of  several  main  components. 
The  first  is  how  to  receive  and  handle  the  request  object.  Since  this  thesis  uses  the 
Metcast  server  to  return  forecast  values,  at  some  point  the  request  object  must  be 
converted  into  MBL.  As  the  geographic  location  of  interest  was  changed,  or  as  the 
desired  forecast  parameters  were  changed,  the  agent  would  have  to  change  the  structure 
of  the  Metcast  request  accordingly.  The  fact  that  this  thesis  is  a  proof  of  concept  look  at 
this  topic  allows  us  to  simplify  this  by  “hardwiring”  the  agent  with  request  language  for 
our  three  pre-selected  values.  After  the  request  language  has  been  defined,  the  agent  must 
establish  an  http  connection  with  the  Metcast  server  and  deliver  the  request.  As  that  data 
server  receives  and  responds  to  the  request,  an  input  stream  must  then  be  initiated  to 
capture  that  data.  Finally,  the  captured  data  must  be  processed  in  such  a  way  so  that  the 
forecast  object  array  is  created  and  ready  for  delivery. 

D,  THE  STRUCTURE  OF  THE  ENVIRONMENT 

Once  the  architecture  of  the  agent  itself  was  established,  how  it  would  be  placed 
within  its  environment  was  a  topic  worthy  of  considerable  thought.  If  we  conceptually 
understand  the  desired  effect  of  FORCEnet,  we  can  envision  how  the  agent  would  be  free 
to  interact  with  any  planning  software.  With  access  to  data  servers  on  which  to  run  the 
WAg,  it  might  also  be  desirable  to  structure  the  environment  to  incorporate  this 

capability.  The  way  in  which  the  agent  fits  within  its  environment  can  also  be  simplified 
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so  that  the  work  on  this  proof  of  concept  attempt  at  implementing  this  idea  is  streamlined. 
Realistically,  each  of  these  individual  possibilities  represents  a  progressive  step  toward 
the  realization  of  an  overall  fully  integrated  computer  architecture. 

In  a  perfect  FORCEnet  environment,  the  WAg  would  be  able  to  exchange 
information  with  any  command  and  control  software  through  pre-established  interfaces. 
This  sort  of  view  is  presented  in  Figure  2.  Here,  SEAWAY  would  be  able  to  create 
request  objects  on  its  own  and  initiate  an  http  connection  directly  with  the  WAg.  The 
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Figure  2.  The  WAg  in  a  FORCEnet  Environment. 


agent,  in  turn,  would  be  running  on  a  centralized  server.  This  would  allow  the  agent  to 
receive  multiple  requests  from  different  warfare  planning  tools,  as  permitted  by  the 
allocated  bandwidth  and  computing  power.  The  agent  could  then  receive  model 
information  at  that  centralized  location,  process  it  and  return  forecast  objects  as  desired 
by  the  requesting  software.  The  forecast  objects  could  then  be  imported  directly  into  the 
planning  software  and  processed  immediately.  Ideally,  once  it  had  received  forecast 
information  the  planning  software  would  also  be  able  to  display  the  appropriate 
symbology  for  that  forecast  to  its  user  via  its  graphical  user  interface  (GUI).  If  the 
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command  and  control  software  was  also  configured  to  incorporate  threshold  information 
for  operating  platforms,  it  could  also  use  its  GUI  to  indicate  the  effeet  the  forecast 
conditions  would  have  on  the  planned  exereise.  It  is  fairly  easy  to  see  that  this  sort  of 
arehitecture  would  have  several  advantages.  First,  there  are  less  “moving  parts”  to  this 
sort  of  structure,  sinee  the  planning  tool  communicates  directly  with  the  WAg.  Second, 
the  agent  is  running  at  a  eentral  loeation,  whieh  allows  it  to  traek  and  respond  to  requests 
from  differing  locations.  Third,  the  overall  bandwidth  required  for  communication  is 
reduced  since  only  the  request  and  foreeast  objeets  are  transmitted  instead  of  entire  model 
runs. 

Since  we  do  not  yet  operate  in  the  ideal  FORCEnet  environment  just  mentioned, 
we  must  eonsider  other  means  of  integrating  the  WAg  with  its  environment.  The  main 
area  of  difficulty  is  found  at  the  interfaee  with  the  warfare  planning  software.  Without 
integration  during  development,  these  pieees  of  software  will  have  no  way  of  ereating  the 
request  object  that  can  be  sent  to  the  WAg.  Moreover,  they  will  have  no  way  of 
deciphering  the  returned  foreeast  object  into  meaningful  and  useful  information.  In  order 
to  bridge  this  gap  the  command  and  control  tool  must  have  some  loeal  way  of 
instantiating  these  objects  and  passing  information  back  and  forth.  This  was  a  significant 
problem  eneountered  when  working  with  SEAWAY. 

Computer  software  usually  passes  information  back  and  forth  through  an 
application  program  interface  (API).  An  API  is  a  sort  of  gate  through  which  data,  or 
information,  must  be  passed  in  order  to  import  or  export  it.  After  meeting  with  the  CDM 
Teehnology  developers  it  became  evident  that,  in  their  own  words,  the  use  of  the 
SEAWAY  API  required  complex  bundling  and  packaging  in  order  to  pass  data.  The 
arehiteeture  of  the  SEAWAY  program  itself,  however,  provided  a  way  of  bypassing  this 
problem.  As  stated  in  a  preceding  chapter,  the  SEAWAY  program  uses  a  manager  entity 
to  create  and  run  the  instances  of  its  agents.  This  would  allow  the  creation  of  a  sealed- 
down,  loeal  version  of  the  WAg  that  eould  be  instantiated  by  this  manager.  Since 
SEAWAY  would  be  creating  the  instanee  of  this  loeal  agent  object  it  would  then  be  able 
to  use  and  understand  the  request  and  forecast  objects.  This  structure  is  diagrammed  in 
Eigure  3. 
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When  designed  in  this  manner,  as  the  WAg  ereates  a  request  objeet  as  per  the 
instruetions  of  the  planning  tool,  the  loeal  agent  then  establishes  an  http  eonneetion  with 
a  full  version  of  the  agent  running  on  a  data  server.  The  request  objeet  is  passed,  the 
appropriate  model  information  downloaded  and  proeessed,  and  then  the  foreeast  objeet  is 
ereated  and  returned.  As  with  the  previous  design,  this  sort  of  strueture  keeps  the  required 
bandwidth  low  and  allows  for  a  eentralized  proeessing  of  the  requests.  In  this  ease, 
however,  there  is  some  added  eomplexity  in  that  an  additional  level  of  eommunieation  is 
required  between  the  loeal  WAg  and  the  eommand  and  eontrol  tool.  Additionally,  this 
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Figure  3.  The  WAg  Bridging  the  Proprietary  Information  Gap 


eommunieation  problem  would  have  to  be  solved  for  every  different  type  of  planning 
software  that  the  agent  would  interaet  with.  This  sort  of  design  strueture  could  be  viewed 
as  a  way  of  solving  the  interoperability  problem  until  wider  implementations  of 
FORCEnet  were  in  place. 

The  final  structure  of  the  agent  environment  we  will  examine  is  the  one  that  was 

actually  implemented  within  this  thesis.  During  the  course  of  this  research  it  was  not 
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always  practical  to  plan  on  running  a  full,  or  main,  version  of  the  WAg  on  a  data  server 
remotely  located  from  the  Naval  Postgraduate  Sehool.  As  just  discussed,  however, 
SEAWAY  can  initiate  and  manage  agents  locally.  With  this  in  mind  if  SEAWAY  simply 
instantiated  the  full  WAg  locally  instead  of  a  smaller  version  the  results  would  essentially 
be  the  same.  Eigure  4  outlines  the  organization  of  this  structure.  Operating  within  an 
environment  configured  in  this  way,  SEAWAY  would  be  able  to  send  and  receive  the 
request  and  forecast  objects  via  the  main  WAg.  The  main  WAg  would  then  create  the 


SEAWAY 


Main  Wx  Agent 


Request  Object 

-  Request  ID 

-  Request  Fulfilled 

-  Forecast  ID 

-  Granularity 

-  Forecast  Area 

-  Forecast  Timeframe 

Model  Processing  Methods 

Forecast  Object 

-  Forecast  ID 

-  Forecast 

METCAST 


Eigure  4.  The  WAg  During  Thesis  Research. 


desired  request  in  MBE,  send  it  to  the  Metcast  server  via  an  http  connection,  and 
download  the  desired  model  output.  That  model  output  could  then  be  processed  locally 
and  used  to  create  the  final  forecast  object.  The  main  advantage  of  this  was  added 
simplicity  for  the  programmer.  It  was  also  apparent  that  since  both  types  of  objects  were 
still  created,  http  connections  were  used  to  send  and  receive  information,  and  the  model 
output  was  still  processed  in  the  same  manner,  the  use  of  this  design  structure  from  a 
proof-of-concept  approach  was  still  valid.  The  main  disadvantage  to  this  sort  of  structure 
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was  that  if  it  were  implemented  Navy-wide,  huge  increases  in  bandwidth  usage  would 
result.  In  this  case  instead  of  sending  small  request  or  forecast  objects,  full  model  runs 
would  be  transmitted.  In  this  type  of  scenario,  similar  requests  could  be  made  by  different 
pieces  of  software  and  there  would  be  no  way  of  recognizing  this  and  preventing  the 
duplication  of  effort.  In  an  academic  environment,  however,  these  effects  were  noted  in 
case  of  a  larger  implementation,  but  deemed  insignificant  to  the  outcome  of  the  research. 
It  is  within  this  structure  of  both  the  environment  and  the  WAg  that  the  testing  presented 
in  the  following  chapter  was  conducted. 
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V.  TESTING 


As  we  move  into  the  testing  phase  of  this  thesis,  it  is  important  to  fully  deseribe 
where  the  WAg  stands  after  the  initial  development  stage.  When  activated,  the  agent  uses 
a  hardcoded  request  object,  establishes  an  http  connection  with  the  FNMOC  Metcast 
server,  and  sends  a  request  for  gridded  COAMPS  output,  either  wind  or  12-hour 
precipitation,  or  WAM  significant  wave  heights.  The  agent  then  establishes  an  input 
stream  to  read  that  model  output  into  a  data  structure  defined  by  the  program.  That  data 
structure  is  then  decoded  so  that  three  main  arrays  can  be  produced.  Arrays  are  created 
for  the  latitude  positions,  the  longitude  positions,  and  the  requested  data.  These  arrays  are 
then  combined  and  passed  into  the  main  body  of  the  forecast  object.  With  a  general 
understanding  of  the  functionality  the  agent  provides,  we  can  now  move  forward  and 
examine  how  to  test  it. 

The  testing  of  the  WAg  poses  a  unique  challenge  due  the  very  nature  of  the 
software  itself  This  agent  was  designed  to  be  a  fresh,  transformational  look  at  how  to 
handle  meteorological  and  oceanographic  data  and  best  make  it  available  to  operational 
users.  A  major  goal  of  the  agent  is  to  be  able  to  bridge  proprietary,  insular  applications 
(technological  stovepipes)  and  allow  a  freer  exchange  of  information  within  a  FORCEnet 
environment.  Due  to  its  nature,  therefore,  when  the  WAg  is  operating  perfectly,  its 
presence  would  be  only  minimally  apparent  to  the  user.  The  only  indication  the  user 
would  have  that  the  agent  was  functioning  properly  would  be  a  visible  integration  of 
weather  data  into  the  planning  process.  In  this  sense,  then,  the  WAg  is  either  functioning 
properly  as  an  entity  that  can  obtain  and  process  data  or  it  is  not.  The  idea  of  testing 
becomes  a  binary  value  where  either  the  agent  works  completely  or  it  does  not.  For  this 
reason,  we  must  examine  other  means  of  evaluating  the  agent  and  discuss  their  validity. 

When  considering  how  best  to  evaluate  the  effectiveness  of  the  developed  WAg, 
it  may  be  important  from  one  perspective  to  validate  the  forecast  object  output  for 
correctness.  This  sort  of  testing  mechanism  would  focus  on  evaluating  the  accuracy  of  the 
output  data  by  comparing  it  with  some  sort  of  control.  For  example,  the  testing  of  this 
thesis  could  then  consist  of  a  side-by-side  comparison  of  agent  output  with  Joint  METOC 
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Viewer  (JMV)  output.  Even  a  qualitative  eomparison  of  these  outputs  would  give  us  a 
feel  for  how  aceurately  the  WAg  was  handling  the  COAMPS  and  WAM  grids  and  would 
ensure  that  data  was  not  getting  eorrupted  or  mishandled  during  the  packaging  of  the 
forecast  object.  It  must  be  recognized,  however,  that  this  sort  of  testing  would  be  largely 
trivial.  Since  both  JMV  and  the  WAg  use  the  same  source  for  their  data,  showing  that  the 
data  remained  unaltered  within  the  agent  program  would  not  be  a  significant  or  rigorous 
evaluation.  It  is  for  this  reason,  that  testing  of  the  WAg  should  be  more  effect  driven,  and 
focus  on  how  a  properly  functioning  agent  would  contribute  to  warfare  planning. 

In  a  perfect  testing  environment,  the  effectiveness  of  the  WAg  would  be  evaluated 
as  it  imported  meteorological  data  directly  into  the  SEAWAY  program.  Unfortunately, 
this  sort  of  integration  would  obviously  require  the  full  incorporation  of  the  WAg  by 
software  developers  from  CDM  Technologies,  Inc  into  their  program.  Obviously,  this 
was  not  always  a  practical  expectation  during  the  research  and  development  of  this  thesis. 
As  such,  a  scaled  down  examination  of  the  effect  or  impact  of  this  functionality  must  be 
evaluated  instead.  This  can  be  accomplished  by  framing  a  warfare  scenario  within 
SEAWAY,  and  then  exploring  how  importing  wind,  wave  or  precipitation  data  directly 
into  this  program  would  impact  operational  planning.  This  testing  mechanism  was 
deemed  to  provide  a  more  significant  evaluation  of  the  value  of  the  WAg,  than  a  mere 
qualitative  comparison. 

A,  THE  SCENARIO 

According  to  its  basic  training  manual  (CDM,  2003),  SEAWAY  was  designed  to 
support  Marine  Air/Ground  Task  Eorce  (MAGTE)  staff  planning  and  was  created  for,  and 
funded  by,  the  Marine  Corps  Systems  Command  (MARCORSYSCOM)  and  the  Marine 
Corps  Warfighting  Eab  in  Quantico  Virginia.  Eor  this  reason,  it  seemed  most  logical  to 
create  an  amphibious  assault  scenario  utilizing  these  kinds  of  forces  to  assess  the  agent 
impact.  It  also  seemed  logical  to  choose  a  geographic  region  that  had  current  operational 
significance.  As  such,  the  Korean  Peninsula  was  chosen  as  the  target  for  this  hypothetical 
assault.  This  is  pictured  in  Eigure  5.  It  seems  reasonable  to  assume  that  at  some  point,  if 
tensions  concerning  the  development  of  nuclear  capabilities  by  the  North  Korean 
government  continue  to  escalate,  an  amphibious  operation  mounted  from  the  Sea  of 
Japan  might  be  an  all  too  real  possibility.  Erom  this  zoomed  out  view  of  the  area  of 
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interest  we  see  some  of  the  basic  functionality  of  SEAWAY.  The  program  provides  a 
general  outline  of  the  geographic  region,  as  well  as  several  menu  bars.  Without  going  into 
a  detailed  description  of  each  one,  we  can  generally  see  that  there  is  a  vertical  menu  bar 
along  the  left  side  of  the  screen  that  represents  the  SEAWAY  agents  and  there  is  a 
horizontal  menu  bar  across  the  top  of  the  screen  for  map  navigation  within  the  program. 
Here  we  can  also  see  the  aforementioned  weather  agent  that  is  already  a  part  of 
SEAWAY,  however,  the  testing  being  documented  here  will  highlight  the  added  utility 
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Figures.  Zoomed-Out  Scenario  View. 


that  the  WAg  will  provide.  The  units  created  for  this  supposed  operation  are  also  visible, 
and  will  be  discussed  next  utilizing  a  zoomed  in  view  of  the  operational  area  of  interest. 
The  top  menu  bar  also  shows  the  current  map  scale  of  1:14,400,000. 

As  we  zoom  in  closer  over  the  west  coast  of  North  Korea,  the  particulars  of  the 
scenario  become  clearer  (Figure  6).  We  see  a  Sea  Base  established  offshore  consisting  of 

the  Essex  Amphibious  Readiness  Group  (ARG)  with  three  ships,  the  USS  ESSEX  (EHD 
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2),  the  USS  MESA  VERDE  (LED  17),  and  the  USS  PEARL  HARBOR  (LSD  49).  A 
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Marine  tactical  base  has  been  established  ashore,  which  is  designated  as  North  Korea 
FOB.  There  are  also  three  Marine  Task  Forces  (TF)  securing  the  area,  TF  Axe,  TF 
Sword,  and  TF  Spear,  each  of  which  has  a  weapons  company  and/or  an  infantry 
company.  There  are  two  craft  landing  zones,  CLZ  Eagle  and  CLZ  Pelican,  and  one 
Helicopter  Landing  Zone,  HLZ  Vulture.  Delivery  routes  for  logistical  support  are 
represented  between  the  ESSEX  ARG  and  all  four  landing  areas.  The  routes  highlighted 
in  blue  are  for  utilization  by  landing  craft  only,  the  routes  highlighted  in  red  are  for  use 
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Figure  6.  Zoomed-In  Scenario  View. 


by  aircraft  only,  and  the  routes  highlighted  in  purple  are  for  use  by  both  landing  craft  and 
aircraft.  There  are  three  enemy  units  inland  that  are  the  objective  of  the  assault,  TF  Red 
and  supporting  infantry  units.  Inf  3  and  Inf  4.  The  companies  from  TF  Sword  will 
conduct  the  main  ground  assault  of  this  operation  on  TF  Red,  with  supporting  helicopter 
assaults  on  the  two  enemy  infantry  units  from  TF  Axe  and  Spear.  With  a  basic  warfare 
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scenario  in  place  we  can  now  examine  how  weather  parameters  may  impact  the  planning 
of  this  amphibious  assault  and,  by  extension,  the  importanee  of  the  WAg. 

This  scenario  was  evolved  to  this  point  temporally  because  it  highlights  the 
functionality  of  SEAWAY.  It  would  have  been  easy  to  ereate  an  offshore  Sea  Base  and 
depiet  an  initial  assault  into  the  landing  area.  With  ground  troop  ashore  executing  various 
schemes  of  maneuver,  however,  the  complexity  of  SEAWAY  is  more  effectively 
showcased.  Within  this  sort  of  scenario,  SEAWAY  can  calculate  usage  rate  for  supplies, 
determine  the  resulting  logistical  requirements,  and  evaluate  the  various  delivery  options. 
This  scenario  could  have  been  limited  to  an  initial  amphibious  assault,  but  it  was 
determined  that  a  scenario  containing  a  full  description  of  established  bases  and 
advaneing  units  would  be  more  effeetive. 

B,  THE  WEATHER  IMPACT 

It  should  be  fairly  obvious,  to  even  the  most  casual  observer,  that  within  this 
operational  seenario  the  proper  assessment  of  environmental  conditions  would  play  a 
vital  role  in  the  success  of  the  assault.  In  order  to  evaluate  this  impact,  we  will  input  in 
turn  each  of  the  three  types  of  data  that  the  WAg  is  capable  of  providing.  In  some 
instances,  we  will  see  that  the  delivery  capabilities  of  the  agent  eoincide  nieely  with  the 
display  capabilities  of  the  SEAWAY  program.  In  other  cases,  the  WAg  will  provide 
information  that  would  seem  desirable  to  warfare  planners,  but  that  is  not  currently 
supported  by  the  latest  version  of  SEAWAY.  This  proeess  is  not  intended  to  imply  that 
there  are  any  gaps  in  the  utility  provided  by  CDM’s  software,  but  rather  to  help  define 
some  of  the  future  funetionality  that  should  be  required  by  the  METOC  eommunity 
within  EORCEnet.  The  reader  should  understand  that  SEAWAY  was  produced  to  be  a 
logistical  decision-aid,  not  an  environmental  assessment  tool.  Studies  sueh  as  this  one  are 
required  to  develop  fully  the  required  capabilities  of  the  weather  agent  portion. 

1.  12-Hour  Precipitation 

The  amount  of  preeipitation  that  falls  over  a  combat  area  ean  have  a  significant 
impact  upon  the  effeetiveness  of  employment  of  equipment  and  personnel.  Eor  this 
reason,  it  seemed  important  to  introduce  an  area  of  rainfall  into  the  assault  seenario  and 
observe  how  it  affects  the  various  assets  represented  within  SEAWAY.  COAMPS 
ealculates  this  parameter  and  Metcast  returns  amounts  of  precipitation  in  kilograms  per 
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square  meter  per  latitude/longitude  coordinate.  This  correlates  well  with  SEAWAYs 
display  capabilities.  Within  SEAWAY  the  user  can  define  weather  areas  that  are  bounded 
polygons  representing  environmental  conditions.  These  environmental  conditions  can 
include  dust  storms,  fog,  hail,  tropical  storms,  hurricane,  and  precipitation  varying  in 
intensity  from  drizzle  to  thunderstorms.  When  returning  a  forecast  object  that  contains 
12-hour  precipitation  data,  the  magnitude  at  each  grid  point  could  be  correlated  to  the 
intensity  of  the  precipitation.  This  would  allow  the  creation  of  an  appropriately  labeled 
bounded  polygon  within  SEAWAY  that  was  denoted  by  the  proper  weather  symbology. 


^SEAWAY  BE® 


Eigure  7.  Area  of  Thunderstorms  Off  of  the  North  Korean  Coast. 

We  examine  the  impact  this  kind  of  data  would  have  on  operational  planning 
within  SEAWAY  by  placing  an  area  of  thunderstorms  and  rain  between  the  ESSEX  ARG 
approach  and  retirement  lanes  and  the  North  Korean  shore.  In  Eigure  7  we  can  see  that 
this  area  is  labeled  North  Korean  Tstorms,  and  that  it  has  an  almost  immediate  effect.  Our 
first  indication  that  there  is  a  problem  with  our  planned  operations  is  that  the  Route  agent 
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on  the  left  menu  bar  turns  red  and  displays  the  number  8.  This  indicates  that  there  are 
unfavorable  conditions  present  that  will  severely  degrade  or  prevent  the  movement  of 
supplies  along  the  assigned  delivery  routes.  Obviously,  the  air  and  sea  routes  that  connect 
the  ESSEX  ARG  and  CEZ  Pelican,  HEZ  Vulture,  and  the  North  Korean  EOB  will  all  be 
severely  impacted  by  these  conditions.  By  clicking  on  the  Route  agent,  we  get  the  more 
detailed  description  of  the  individual  alerts  as  shown  in  Eigure  8.  Here,  a  text  message 
gives  a  more  detailed  description  of  the  problems  encountered  along  each  of  the  eight 
routes  that  run  through  this  particular  hazardous  area.  In  each  case  the  message  ultimately 
indicates,  “No  transport  operations  on  this  route  possible.” 
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Eigure  8.  Alert  Messages  in  Response  to  Offshore  Thunderstorms. 


For  this  particular  forecast  parameter,  we  see  that  the  SEAWAY  Weather  and 
Route  agents  work  together  very  effectively  to  compare  forecast  conditions  with  asset 
capability.  This  intelligent  comparison  is  a  desirable  capability  that  could  be  an  effective 

example  of  using  of  available  data  when  needed.  Providing  reach-back  capability  to 
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provide  this  data  as  required  is  a  solid  example  of  FORCEnet  implementation,  and  is  the 
type  of  utility  the  WAg  will  provide  when  ineorporated  into  the  SEAWAY  program.  To 
develop  this  idea  further,  ultimately  we  should  be  working  towards  an  environment 
where  all  available  data  is  integrated  and  available  at  the  push  of  a  virtual  button.  This 
data  eould  inelude  Doppler  radar  imagery  from  near-by  land  stations,  in-situ 
measurements  from  advanee  Speeial  Eorees  units,  available  satellite  imagery  of  the  area 
of  interest,  and  even  taetieal  radar  assessments  of  the  environment  from  offshore  naval 
assets.  This  partieular  weather  parameter  is  also  a  good  example  of  an  environmental 
eondition  that  SEAWAY  does  a  good  job  of  representing.  The  program  is  able  to 
qualitatively  break  out  areas  of  preeipitation  based  on  intensity  and  then  visually 
represents  them  to  the  user  in  a  elear,  easy  to  understand  manner.  The  warfare 
eommander  gets  immediate  feedbaek  on  how  this  type  of  weather  will  impaet  the 
employment  of  their  assets  within  the  same  software  package  that  he  or  she  is  using  to 
plan  the  operation.  The  technological  stovepipe  is  effectively  crossed,  or  broken-down,  in 
a  EORCEnet-like  fashion. 

2,  Significant  Wave  Height 

Significant  wave  height  is  another  meteorological  parameter  that  can  play  a  major 
role  in  planning  and  executing  amphibious  operations.  As  the  term  “amphibious”  implies, 
many  of  the  delivery  vehicles  for  equipment  and  personnel  travel  either  on  or  through  the 
water.  Thus,  the  height  of  the  waves  along  the  surface  of  the  water  can  often  determine 
whether  or  not  an  assault  can  be  executed  or  supported.  This  is  represented  well  by 
significant  wave  height,  which  is  defined  as  the  average  height  of  the  highest  one-third  of 
the  waves  present.  WAM  calculates  this  parameter  and  Metcast  returns  it  in  terms  of 
height  in  meters  per  latitude/longitude  coordinate.  The  most  noticeable  difference  in  how 
this  parameter  is  represented  within  SEAWAY  is  that  the  user  cannot  define  a  weather 
area  to  display  this  data.  Instead,  the  user  enters  the  significant  wave  height  as  a  single 
value  within  an  overall  weather  report.  Immediately,  the  defining  of  this  parameter  in 
such  a  manner  should  be  cause  for  further  examination. 

When  input  into  the  SEAWAY  program,  significant  wave  height  is  represented  in 
a  much  more  simplistic  form  than  12-hour  precipitation.  As  stated,  this  parameter  is 
added  as  a  single  entry  in  the  weather  report  section.  Eigure  9  shows,  however,  that  the 
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SEAWAY  agents  still  view  this  piece  of  data  as  significant  to  operations.  In  this  test  the 


user  inputs  a  significant  wave  height  of  10  feet.  Unlike  before,  this  time  the  Route  agent 
did  not  register  an  alert.  Instead,  the  SEAWAY  Weather  agent  returned  an  alert  stating 
that  under  these  conditions,  “No  landing  craft  operations  possible.”  There  was  also  no 
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Figure  9.  Alert  Messages  in  Response  to  a  Significant  Wave  Height  of  10  Ft. 


visual  representation  of  this  prohibiting  parameter  within  the  mapped  environment  since 
it  was  not  associated  with  a  coordinate  location.  This  result  is  significant  since  it  is 
readily  apparent  that  a  single  value  is  not  sufficient  to  describe  significant  wave  height 
within  the  natural  environment.  This  is  a  complex  piece  of  oceanographic  data  that  can 
vary  significantly,  especially  in  a  littoral  environment.  The  WAg  returns  significant  wave 
height  in  an  array  of  latitudes  and  longitudes  with  corresponding  heights  in  meters.  This 
could  be  modified  to  only  return  the  highest  value  in  the  array  and  convert  it  to  feet  in 
support  of  SEAWAY,  but  doing  so  would  be  at  the  expense  of  a  more  accurate  depiction 
of  the  ocean  surface. 
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It  should  be  noted  that  a  savvy  user  of  SEAWAY  could  most  likely  work  around 
the  less  detailed  depiction  of  this  parameter.  For  example,  if  an  operator  was  interested  in 
a  particular  sea  delivery  route  they  could  enter  the  significant  wave  height  along  that 
particular  path  and  then  observe  the  resulting  assessment.  A  similar  change  could  be 
made  for  each  route  of  interest  in  turn.  Of  course,  this  sort  of  manipulation  by  the  user 
would  be  somewhat  counterproductive  to  a  full  and  descriptive  representation  of  the 
operational  environment  and  its  impact  on  the  movement  of  personnel  and  supplies. 

3.  Surface  Wind 

In  addition  to  12-hour  precipitation  and  significant  wave  height,  surface  wind  is 
also  an  environmental  parameter  that  can  have  a  major  impact  on  most  military 
operations.  In  the  case  of  an  amphibious  assault,  surface  winds  can  play  a  major  role  in 
troop  movement,  support,  and  Sea  Basing.  COAMPS  calculates  this  parameter  and 
Metcast  returns  it  in  terms  of  the  u  and  v  components  in  meters  per  second  per 
latitude/longitude  coordinate.  As  with  significant  wave  height,  SEAWAY  does  not 
provide  functionality  to  display  this  as  a  weather  area.  Instead,  as  before,  surface  wind  is 
entered  as  a  single  value  for  both  wind  speed  and  direction  within  the  operational  area. 
We  will  see  that  this  characterization  of  surface  wind,  and  how  the  SEAWAY  program 
incorporates  this  parameter,  is  worth  some  discussion. 

When  input  into  SEAWAY,  wind  speed  and  direction  has  little  or  no  effect  on  the 
planned  operations.  In  Figure  10,  a  wind  speed  of  50  nautical  miles  per  hour  (knots)  from 
a  direction  of  135  was  entered  into  the  program.  This  entry  resulted  in  no  apparent  effect 
within  the  warfare-planning  environment.  None  of  the  system  agents  registered  any  kind 
of  alert  notification,  and  there  was  no  visual  depiction  of  this  wind  speed  or  direction 
displayed  to  the  user.  There  was  no  noticeable  change  made  within  the  planning 
environment  from  the  viewpoint  of  the  operator.  This  observation  was  notable  for  several 
reasons.  First,  from  an  operational  standpoint,  there  is  no  doubt  that  50-knot  winds  would 
severely  hamper  the  movement  of  troops  ashore  as  well  as  the  stability  of  the  established 
Sea  Base.  Second,  the  depiction  of  wind  as  a  singular  value  is  a  poor  representation  of 
this  parameter  as  it  exists  within  the  natural  environment.  As  with  significant  wave 
height,  wind  is  an  environmental  parameter  that  can  differ  substantially  over  short 
distances.  This  is  especially  true  within  the  littoral  environment  where  topography  can 
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significantly  change  wind  direction  and  friction  can  reduce  wind  speeds.  Third,  it  should 
also  be  noted  that  the  variation  of  this  parameter  in  the  vertical  is  not  addressed  by 
SEAWAY.  As  previously  stated,  this  parameter  is  listed  within  the  SEAWAY  weather 
report  as  simply  “wind  speed”  and  “wind  direction”.  It  is  not  even  explicitly  stated 
whether  this  particular  value  is  surface  wind  or  wind  at  some  particular  atmospheric 
level,  as  it  would  pertain  to  aviation  operations.  Within  this  program,  however,  this 
distinction  may  not  be  a  significant  one,  since  regardless  of  the  input  value  there  is  no 
noticeable  resulting  effect.  In  designing  the  WAg,  it  was  stated  that  this  wind  parameter 
would  be  defined  as  surface  wind,  which  would  be  further  defined  as  10-meter  winds.  As 
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Figure  10.  The  SEAWAY  Environment  with  a  Southeast  Wind  of  50  knots. 


such,  the  WAg  was  designed  to  return  an  array  of  latitude  and  longitude  coordinates  with 
corresponding  wind  speeds  in  meters  per  second  and  wind  direction  in  degrees.  As 
before,  this  output  could  be  changed  to  produce  singular  values,  but  at  the  expense  of  a 
more  accurate  depiction  of  the  surface  wind  environment. 
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C.  APPLYING  THIS  TESTING  TO  FORCENET 

This  sort  of  testing  allows  us  to  form  a  vision  of  the  funetionality  and  utility  that 
would  be  available  to  the  user  in  a  perfect  FORCEnet  environment.  In  a  system  where 
information  is  freely  exchanged  and  transmitted  data  could  be  easily  shared,  added 
complexity  could  be  introduced  into  the  display  capabilities.  Higher  resolution  gridded 
output  for  every  environmental  parameter  could  be  used  instead  of  the  singular  values 
currently  considered  for  some  forecast  items.  Additional  parameters,  such  as  directional 
wave  spectrum,  could  also  be  incorporated  into  the  WAgs  delivery  capabilities.  Within 
this  kind  of  system,  sensor  information  from  the  units  within  the  Sea  Base  could  also  be 
used  for  through-the-sensor  assessments  of  the  environmental  conditions.  Users  would 
then  be  able  to  access  in-situ  data  via  the  program  GUI.  Temporal  changes  could  also  be 
expressed,  which  would  enable  warfare  commanders  to  focus  on  the  windows  of  optimal 
conditions  instead  of  evaluating  point  forecasts  for  specific  time  periods.  The  forecast 
data  could  also  be  contained  within  more  complex  data  structures,  such  as  a 
representation  of  winds  that  included  vertical  distribution  along  with  the  horizontal.  The 
application  of  the  ideas  presented  via  this  thesis  within  the  context  of  a  FORCEnet 
environment  open  the  door  to  the  adequate  delivery  of  virtually  any  environmental 
parameter. 

It  should  be  noted  here  that  even  upon  the  completion  of  this  thesis,  research  into 
the  continued  development,  refinement,  and  implementation  of  this  agent  will  continue. 
The  author  will  be  writing  an  additional  thesis  over  the  next  six  months  that  will  focus 
more  on  the  computer  science  aspects  of  this  project.  The  planned  improvements  will 
include  getting  the  WAg  fully  integrated  into  SEAWAY,  conducting  more  refined  impact 
assessments,  and  expanding  the  utility  provided  by  the  WAg.  The  WAg  will  also  be  run 
on  a  remote  data  server  with  the  local  version  of  the  agent  running  alongside  the 
command- and-control  tool,  so  that  request  and  forecast  objects  can  be  exchanged.  This 
thesis  served  as  a  proof-of-concept  consideration  of  how  agents  can  be  implemented 
within  the  METOC  community,  the  follow-on  thesis  will  take  further  steps  to  make  that 
implementation  a  reality. 

The  observations  noted  within  this  chapter  are  not  presented  as  a  criticism  of  the 

SEAWAY  program.  As  examples  to  the  contrary,  the  way  in  which  SEAWAY  represents 
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precipitation  and  incorporates  vehicle-operating  parameters  into  the  assessments  of  its 
agents  can  be  seen  as  excellent  ideas.  Rather,  these  observations  are  intended  as  examples 
of  how  this  sort  of  testing  can  help  define  future  meteorological  or  oceanographic 
requirements  for  FORCEnet.  Funding  is  currently  being  allocated  and  distributed  for  the 
production  of  systems  that  can  provide  the  functionality  that  would  be  required  in  support 
of  FORCEnet.  This  testing  emphasizes  that  in  order  for  the  METOC  community  to 
ensure  that  this  software  will  be  able  to  effectively  handle  and  accurately  represent 
environmental  parameters,  we  must  provide  developers  with  a  set  of  standard  functional 
requirements.  Failure  to  do  so  may  result  in  the  production  of  software  that  displays  this 
information  in  a  format  that  is  either  undesirable  or  ineffective  in  describing  the 
environment. 

Some  of  these  functional  requirements  should  establish  the  kinds  of  visual 
representation  our  community  desires  for  weather  parameters.  This  type  of  statement 
could  include,  for  example,  an  assertion  that  all  environmental  data  will  be  displayed  as 
polygons  defined  by  latitude/longitude  boundaries  referenced  to  one  particular  datum.  It 
could  also  require  that  it  be  possible  to  overlay  these  polygons  on  whatever  mapping  or 
display  capability  the  software  would  incorporate.  Another  requirement  could  be  whether 
or  not  it  was  necessary  to  include  the  representation  of  standard  weather  symbology 
within  these  environments.  By  detailing  exactly  the  display  functionality  that  was 
desired,  or  required,  we  could  avoid  ineffective  visual  representation  of  environmental 
parameters  within  FORCEnet  programs. 

Other  functional  requirements  set  forth  by  the  METOC  community  could 
establish  how  the  exchange  of  weather  data  would  occur.  For  example,  in  a  net-centric, 
FORCEnet  environment  the  http  standard  could  be  adopted.  Drilling  down  further,  how 
each  type  of  parameter  would  be  passed  could  be  detailed.  For  example,  within  this  thesis 
it  was  defined  that  the  12-hour  precipitation  data  would  be  passed  as  an  array  of  values. 
Within  this  array,  latitude  and  longitude  would  be  represented  by  parsed  integers  and 
precipitation  by  integers.  By  defining  how  the  data  our  community  provides  should  be 
represented  and  exchanged  within  a  FORCEnet  environment,  we  take  the  necessary  steps 
required  to  ensure  that  the  proper  interfaces  will  be  in  place  as  needed. 
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Defining  functional  requirements  can  be  a  powerful  integration  tool.  These  ensure 
that  the  groundwork  is  in  place  to  freely  exchange  environmental  data,  and  that  the 
software  architecture  present  can  accommodate  meteorological  and  oceanographic 
parameters.  With  this  functionality  available,  the  METOC  community  would  be  poised  to 
ensure  that  the  consideration  of  environmental  conditions  would  be  fully  incorporated 
into  the  FORCEnet  structure  and,  thus,  into  the  regular  planning  and  execution  of  all 
operations. 
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VI.  CONCLUSIONS 


There  are  several  main  conclusions  that  can  be  drawn  from  this  thesis.  The  first  of 
these  is  that  software  agents  are  a  viable  means  of  processing  data  within  the  METOC 
community  and,  in  larger  terms,  within  the  Department  of  Defense.  The  second 
conclusion  is  that  this  agent  architecture  is  an  implementation  that  is  in  direct  support  of 
FORCEnet.  The  final  main  conclusion  of  this  thesis  is  that  the  creation  of  defined  sets  of 
METOC  requirements  are  vital  to  ensure  that  weather  parameters  are  effectively  and  fully 
integrated  into  the  developing  FORCEnet  environment. 

A,  METOC  TRANSFORMATION  THROUGH  APPLYING  AGENTS 

As  described  in  Chapter  II  and  illustrated  in  Chapter  V,  software  agents  are  a 
versatile  and  powerful  means  of  processing  and  manipulating  data.  Within  the  context  of 
this  thesis,  the  WAg  was  used  to  download  numeric  model  output,  process  that  raw  data, 
and  then  package  it  in  a  usable  format.  This  was  a  relatively  simple  example  of  a  reactive 
agent,  but  this  sort  of  implementation  serves  as  a  proof-of-concept  starting  point  for  more 
advanced  applications.  In  future  versions,  the  WAg  might  employ  more  cognitive 
processing  approaches.  An  example  of  this  would  be  an  agent  that  could  track  forecasts 
and  verifications  for  different  models  in  certain  geographic  areas  of  interest.  This  agent 
could  then  determine  which  model  was  exhibiting  better  performance  in  each  region  and 
create  an  ensemble  forecast  for  its  customer.  Cognitive  agents  might  also  be  able  to 
assess  mission  parameters  and  return  windows  of  time  during  which  optimal  conditions 
exist.  Two  other  students  at  NPS  are  currently  researching  thesis  topic  related  to  agents 
with  this  type  of  complexity.  One  is  looking  into  the  use  of  agents  to  produce  composite 
hurricane  track  forecasts  using  genetic  scoring  algorithms  to  assess  various  model 
performances.  The  other  is  researching  the  use  of  agents  to  automatically  consider 
vertical  wind  shear  in  the  planning  and  execution  of  ordinance  delivery.  This  type  of 
powerful  processing  could  transcend  the  traditional  method  of  point  forecasting  and  shift 
focus  to  achieving  the  ultimate  goals  of  the  warfighter  instead.  Software  agents  that 
evaluate  environmental  conditions  in  different  ways  could  replace  TDAs  as  a  means  of 
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providing  tailored  support  on  a  24/7  basis.  The  power  of  this  teehnology  is  derived  from 
the  realization  that  there  is  virtually  no  limit  to  the  eomplexity  with  whieh  agents  ean  be 
imbued. 

The  implementation  of  autonomy  within  an  agent  environment  eould  also  change 
how  manpower  is  structured  within  the  METOC  community.  In  a  time  if  fiscal  constraint, 
more  basic  forecasting  tasks  could  be  performed  by  complex  agents  that  could  create, 
assess,  and  revise  products  as  necessary.  With  less  routine  duties  to  complete,  additional 
personnel  might  be  free  for  more  effective  employment.  Better  utilizing  our  manpower 
resources  would  streamline  budget  requirements,  and  might  possibly  ease  our  transition 
to  a  more  compact  fighting  force.  This  additional  autonomy  would  be  the  next  iteration  of 
the  WAg  development,  which  would  move  beyond  the  reactive  agent  presented  here. 

B,  SUPPORTING  FORCENET  THROUGH  AGENTS 

For  several  reasons,  the  use  of  software  agents  is  a  concrete  example  of  the 
implementation  of  main  FORCEnet  tenets.  This  thesis  illustrated  a  case  where  this 
technology  was  used  to  cross  the  boundaries  of  proprietary,  insular  software.  Crossing 
these  pre-existing  boundaries  allows  information  to  be  passed  between  otherwise 
incompatible  software.  This  freer  interchange  of  data  and  information  is  in  direct  support 
of  the  FORCEnet  concept,  where  every  data  repository  becomes  a  node  in  the  larger  net- 
centric  environment.  Each  node,  then,  becomes  capable  of  delivering  data  on  an  as- 
needed  basis.  Moreover,  the  delivered  parameters  arrive  in  a  format  that  is  immediately 
usable  to  the  native,  requesting  software.  Agents  also  support  the  focus  on  reach-back 
capability  via  web  services.  The  WAg  utilized  http  connections  to  send  requests  and 
receive  data.  This  enables  a  globally  distributed  usage  that  corresponds  directly  with  the 
actual  worldwide  commitments  of  the  U.S.  Armed  Forces.  By  using  common  standards 
to  create  this  software  and  ensuring  that  implementations  are  platform  and  operating 
system  independent,  extensibility  and  forward/backward  compliance  is  secured.  For  all  of 
these  reasons,  software  agents  are  a  suitable  implementation  of  FORCEnet  tenets. 

This  sort  of  structure  would  also  be  conducive  to  implementing  future  advances  in 
weather  sensing  or  forecasting  technology.  We  may  not  be  far  from  the  day  when 
individual  ground  troops  carry  weather  sensors  on  their  gear  harnesses  for  in-situ 

assessments  of  the  environment  as  they  advance.  Combined  with  rapid  microscale 
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modeling  driven  autonomously  by  agents,  this  would  allow  immediate  impaet 
assessments  and  revisions  of  the  operational  pieture.  As  through-the  sensor  teehnology 
eontinues  to  be  developed,  agents  eould  easily  be  modified  to  understand  and  proeess  that 
data  in  new  and  innovative  way.  Onee  the  groundwork  is  in  plaee  for  the  agent-based 
proeessing  and  delivery  of  data,  this  arehitecture  will  be  uniquely  sited  for  rapid 
adaptation  to  aeeommodate  new  sources  of  information. 

C.  DEFINING  COMMUNITY  REQUIRMENTS 

In  a  succinct  way,  the  testing  of  this  thesis  served  as  an  example  of  the  need  for 
the  METOC  community  to  fully  define  and  promulgate  its  functional  requirements  for 
developing  FORCEnet  software.  The  easiest  way  to  ensure  that  computer  programs  will 
be  able  to  share  information  is  to  establish  interfaces  that  are  built  into  each  system.  It 
can  be  assumed  that  money  is  being  allocated  in  order  to  produce  FORCEnet  compliant 
computing  systems.  The  sooner  the  METOC  community  reaches  a  consensus  on  the  data 
we  wish  to  represent,  how  that  data  will  be  structured,  and  the  types  of  display 
capabilities  required,  the  easier  it  will  be  to  incorporate  it  into  developing  technologies. 
This  thesis  defined  three  of  these  parameters:  surface  wind,  12-hour  precipitation  rates, 
and  significant  wave  height.  This  example  could  be  extended  to  include  the  full  range  of 
desired  meteorological  and  oceanographic  parameters. 

Instead  of  simply  defining  system  requirements,  our  community  could  also 
develop  pre-packaged  software  entities,  such  as  the  WAg,  for  developers  to  incorporate. 
As  a  community  if  we  expanded  agent  development  and  then  handed  it  to  developers  as  a 
unit  we  would  ensure  the  capabilities  we  desired  for  use  were  incorporated  into  their 
systems.  At  the  very  least,  creating  this  sort  of  software  bundle  would  allow  us  to  define 
the  API  we  wished  to  work  through. 

D,  TRANSFORMATION:  AN  OFFER  WE  CAN’T  REFUSE 

There  can  be  little  doubt  that  technology  will  continue  to  advance  at  its  current 
exponential  rate,  whether  we  like  it  or  not.  As  a  result,  we  must  either  move  with  it  or  be 
surpassed  by  it.  The  transformation  and  advancement  of  the  METOC  community  must 
incorporate  the  new  and  emerging  Information  Age  technologies  becoming  available 
virtually  every  day.  It  is  through  the  effective  implementation  of  these  tools  that  we  will 
maintain  the  competitive  edge  in  warfighting,  and  more  specifically  the  assessment  of  the 
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natural  environment,  whieh  our  country  has  enjoyed  for  so  long.  Re-evaluating  how  we 
transmit  data  and  incorporate  it  into  our  planning  processes  is  a  healthy  exercise  that 
should  be  repeated  frequently  in  order  to  ensure  it  is  still  relevant  and  current.  The 
utilization  of  agent-based  software  as  a  means  of  processing  data  and  delivering 
information  should  be  a  part  of  this  kind  of  periodic  evaluation.  For  all  of  the  reasons 
presented  here,  software  agents  are  a  versatile,  powerful  means  of  computing  that  will 
become  more  relevant  as  autonomy  and  cognitive  decision  making  begins  to  permeate  the 
world  of  computing. 


48 


LIST  OF  REFERENCES 


Arthur,  W.  B.,  1994;  Inductive  Reasoning  and  Bounded  Rationality.  [Available  online  at 
http://www.santafe.edu/arthur/Papers/El  FaroLhtmll 

CDM  Teehnologies,  Inc.,  2003;  SEAWAY  Version  2.0  Basic  Training  Manual.  [Available 
from  2975  McMillan  Ave.  Suite  272  San  Luis  Obispo,  CA  93401] 

Cebrowski,  A.  K.:  The  Office  of  Force  Transformation;  What  is  Transformation?. 
[Available  online  at  http://www.oft.osd.mil/what  is  transformation.efm] 

Gentges,  D.,  Java  programmed  computer  code.  [Available  from  Fleet  Numerical 
Meteorology  and  Oceanography  Center  7  Grace  Hopper  Ave.  Monterey,  CA  93943] 

Gunderson,  C.  R.  &  Higgins,  S.,  24  February  2004;  Presentation  to  OC4270  (Taetieal 
Oceanography)  at  the  Naval  Postgraduate  School;  Net-centric  Operations. 

http://geoengine.nga.miFmuse-cgi-bin/rast_roam.cgi.  Last  aeeessed  August  2004. 

http://www.metnet.navy.mil/Metcast/.  Last  accessed  August  2004. 

http://www.metnet.navy.miFMetcast/Code/grid-serve.sem.  Last  accessed  August  2004. 

https://www.fnmoc.navy.mi1/PUBLIC/MODEL_REPORTS/MODEL_SPEC/coamps2.0. 
html.  Last  accessed  August  2004. 

Pohl,  J.,  cited  2004;  Transitioning  from  Data  to  Information.  [Available  online  at 
http://www.cadrc.calpolv.edu/pdf/data  information.pdf] 

Reynolds,  C.  W.,  1987:  Flocks,  Herds,  and  Schools:  A  Distributed  Behavioral  Model. 
Computer  Graphics,  21,  25-34. 

Schach,  S.  R.,  2002:  Object-Oriented  and  Classical  Software  Engineering.  5*  ed. 
McGraw-Hill,  290-318. 

Weiss,  G.,  Ed,  \999\Multi  Agent  Systems:  A  Modern  Approach  to  Distributed  Artificial 
Intelligence.  The  MIT  Press,  1-77. 


49 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


50 


INITIAL  DISTRIBUTION  LIST 


1 .  Defense  Teehnieal  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  Sehool 
Monterey,  California 

3.  Dr.  Carlyle  H.  Wash 
Naval  Postgraduate  Sehool 
Monterey,  California 

4.  Dr.  Neil  C.  Rowe 

Naval  Postgraduate  Sehool 
Monterey,  California 

5.  Dr.  Philip  A.  Durkee 
Naval  Postgraduate  Sehool 
Monterey,  California 

6.  LCDR(sel)  Jonathan  J.  Vorrath 
Naval  Postgraduate  Sehool 
Monterey,  California 


51 


